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

111–120 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#111

Post by vertex-four »

lambda wrote: post #101
Corrado wrote: post #98

Earlier quoted context omitted.

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

One thing to recall is that much of the complexity in systemd comes from replacing a whole bunch of dodgy, special purpose code written in shell scripts (init scripts) and in the daemons it manages (daemonization code, various kinds of racy startup dependencies, etc). Just saying "systemd is complex" is fairly sloppy thinking; the question is, is it more or less complex than re-implementing that functionality poorly…

There's significantly less complex ways to do this sort of thing, though. One that I've been looking at implementing into a distro lately is nosh[0] (and execline[1]). Every bit of code is implemented as a separate, independent utility that can be chained together through the nosh/execlineb "shell", which does no parsing and only a tiny bit of lexing.

This way, it's easy to pick and choose what features and complexity each script needs, and the features that you don't use can't affect you. Nothing is running on your system that you don't know about, and there's no complex "magic" anywhere unless you explicitly ran a command which does magic things.

[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar... [1] http://skarnet.org/software/execline/

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#112

Post by SixSigma »

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

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#113

Post by mr_brown »

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

And indeed I just received an email from QNAP:

http://qnap.benchmarkmails26.com/c/v?e=53F45E&c=47C09&l=149F...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#115

Post by vertex-four »

dfc wrote: post #84
mct wrote: post #83

Earlier quoted context omitted.

While this is generally true of newer Debian installations, older machines that have been been regularly updated over the years to stable may still have /bin/sh pointing to bash. I fixed a few of my machines yesterday to use dash.

dash changelog.Debian.gz entry from July 22nd, 2009: * Change the default for the system shell to dash. * Ship /bin/sh in the package and fix the diversion handling for it to make sure /bin/sh is always present. * Set debconf priority to high when upgrading from an existing system. Unless the admin has--for some bizarre reason--set debconf to critical; during one of those "regular updates" the admin would have been p…

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

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#116

Post by neersighted »

mariusz79 wrote: post #93
mariusz79 wrote: post #92

So now we can have dhcp-option-force=114,() { :; }; if hash apt-get 2>/dev/null; then apt-get update -y && apt-get upgrade -y;fi; if hash yum 2>/dev/null; then yum update;fi; to upgrade most vulnerable systems that connect to our network :) What other upgrade commands are there?

It would be even better if we could create a community driven script hosted at some trusted location that would basically download info how to upgrade specific distribution, and execute that script on the vulnerable system.. so something like wget fix && chmod +x fix && ./fix :)

Then what would happen if someone compromised the fix?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#117

Post by dfc »

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

Earlier quoted context omitted.

dash changelog.Debian.gz entry from July 22nd, 2009: * Change the default for the system shell to dash. * Ship /bin/sh in the package and fix the diversion handling for it to make sure /bin/sh is always present. * Set debconf priority to high when upgrading from an existing system. Unless the admin has--for some bizarre reason--set debconf to critical; during one of those "regular updates" the admin would have been p…

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?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#118

Post by neersighted »

hardwaresofton wrote: post #35

Yeah, I don't think anyone has grasped the extent of how dangerous this vuln is -- was it released a little prematurely? is it still in "embargo"? This is hundreds of times worse than heartbleed in terms of scope/attack surface for modern servers... (I say hundreds of times worse because heartbleed was scrape-some-data-till-you-get-private-keys-and-watch-communication, where this is just get-yourself-a-shell-and-pwn-…

It's the ultimate in vulnerabilities. Remote code execution over the network, potentially as root.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#119

Post by MertsA »

Klasiaster wrote: post #13

one more reason for networking done by network-manager or networkd (systemd) instead of bash scripts

NetworkManager still mucks around in /etc/sysconfig/network-scripts and is probably a lot more complicated than it needs to be. I'd like to think that networkd is a better approach with a smaller attack surface but also right now networkd doesn't have the maturity or usage of NetworkManager or crappy network scripts so it would be unwise to suggest that networkd is more secure because of that. Especially when you lump in NetworkManager as another alternative that's done better, if anything I'd rather have no NetworkManager or networkd than have to use NetworkManager on something other than a laptop as random bugs in NetworkManager have personally bit me before.

That being said the design of networkd looks very nice indeed and against my better judgement I'm even running it in something that you could almost consider production.

Post reply on HN