Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shellshock DHCP Remote Code Execution – Proof of Concept

trustedsec.com

Post reply on HN
Print view View original

131–140 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#131

Post by dllthomas »

SixSigma wrote: post #112
1wd wrote: post #97

Is it just me or would it be a good time to learn a bigger lesson from Heartbleed and Shellshock: Minimalism is seriously a good idea. "Features" are not harmless and cost way more than you think. Providing more flexibility or functionality than absolutely necessary should really be considered and called out as defective, smelly and a bad practice.

The plan9 community have been bashing bash for years. "It's got to much code, a shell should just execute shellscript not handle input" Perhaps they'll listen now - haha as if

"It's got to much code, a shell should just execute shellscript not handle input"

Honestly, I'd sooner go the other way.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#132

Post by SixSigma »

dllthomas wrote: post #131
SixSigma wrote: post #112

Earlier quoted context omitted.

The plan9 community have been bashing bash for years. "It's got to much code, a shell should just execute shellscript not handle input" Perhaps they'll listen now - haha as if

"It's got to much code, a shell should just execute shellscript not handle input" Honestly, I'd sooner go the other way.

In plan9 the two functions are totally split. rc doesn't handle any input apart from stdin, stdout and stderr.

The window manager handles input/output and sends bytes to stdout for processing. The environment is a per process filesystem in /proc/$pid/env/ .

Keeping the TTY around is a dumb move. Kill it with fire.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#133

Post by SixSigma »

zorked wrote: post #105
Corrado wrote: post #98

Earlier quoted context omitted.

Which brings to mind the latest push for systemd as an init replacement. :/

You will be shocked to learn that the Linux kernel is actually much bigger :/

Which, in itself, is another disaster.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#134

Post by SixSigma »

jameshart wrote: post #127
1wd wrote: post #97

Is it just me or would it be a good time to learn a bigger lesson from Heartbleed and Shellshock: Minimalism is seriously a good idea. "Features" are not harmless and cost way more than you think. Providing more flexibility or functionality than absolutely necessary should really be considered and called out as defective, smelly and a bad practice.

Arguably an insistence on stitching together systems out of 'do one thing and one thing only' minimalist components is precisely why Shellshock is so bad, though. That so many things delegate setting environment variables to the system shell is what allows a vulnerability like this to be so pervasive. Why does a DHCP client pass server-originated data to a full shell? In some ways, it's a form of minimalism.

In band signalling = bad

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#136

Post by dllthomas »

SixSigma wrote: post #132
dllthomas wrote: post #131

Earlier quoted context omitted.

"It's got to much code, a shell should just execute shellscript not handle input" Honestly, I'd sooner go the other way.

In plan9 the two functions are totally split. rc doesn't handle any input apart from stdin, stdout and stderr. The window manager handles input/output and sends bytes to stdout for processing. The environment is a per process filesystem in /proc/$pid/env/ . Keeping the TTY around is a dumb move. Kill it with fire.

So... not really any difference, in any sense that is remotely relevant. My point was that the shell interface is a much better UI than it is programming language.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#137

Post by vertex-four »

dfc wrote: post #117
vertex-four wrote: post #115

Earlier quoted context omitted.

This assumes that the admin is administering their systems by running apt-get update && apt-get upgrade manually, rather than some automated process.

What automated process for Debian administration is unaware of debconf? This is a honest question. How could an automated Debian administration process not be aware of and interact on some level with debconf?

Does this change default to "yes" on unattended installs? I'd assume it doesn't, because that would be dangerous.

EDIT: Indeed, from the same changelog: debian/dash.NEWS.Debian: when upgrading existing installations, the system shell will not be changed automatically (closes:#539363).

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#139

Post by lk145 »

mr_brown wrote: post #12

I believe there will be plenty of linux NASs that will be vulnerable for the forseeable future. NASs are usually bigger and more functional than routers, they tend to run a more full system. Many of these for exampe run bash as far as I remember: http://www.amazon.com/s/field-keywords=QNAP

Synology released a security advisory outlining the affected Synology NASs: https://www.synology.com/en-global/support/security/bash_she...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#140

Post by Florin_Andrei »

jameshart wrote: post #127
1wd wrote: post #97

Is it just me or would it be a good time to learn a bigger lesson from Heartbleed and Shellshock: Minimalism is seriously a good idea. "Features" are not harmless and cost way more than you think. Providing more flexibility or functionality than absolutely necessary should really be considered and called out as defective, smelly and a bad practice.

Arguably an insistence on stitching together systems out of 'do one thing and one thing only' minimalist components is precisely why Shellshock is so bad, though. That so many things delegate setting environment variables to the system shell is what allows a vulnerability like this to be so pervasive. Why does a DHCP client pass server-originated data to a full shell? In some ways, it's a form of minimalism.

No, it's a form of laziness.
Post reply on HN