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

101–110 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#101

Post by lambda »

Corrado wrote: post #98
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.

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 and incompatibly several dozen other times in various other daemons and startup scripts?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#103

Post by fulafel »

lambda wrote: post #40
jeffmcjunkin wrote: post #2

Note that this will affect devices without listening services. Embedded devices are very likely to be affected for a long time. A note for those trying to reproduce the PoC (as I was yesterday) - ISC's DHCP server only sends client-requested options by default, though this can be overridden [1]. tftpd [2], the software used in the PoC, is likely the easiest way to demo the vulnerability. [1] http://linux.die.net/man/…

I reproduced it with dnsmasq as well; just set up a server with the following options. eth2 is the network adapter that I was using for the test network, and I picked the 10.0.10.0/24 prefix for this particular network. interface=eth2 dhcp-range=10.0.1.100,10.0.10.200,12h dhcp-option-force=114,() { :; }; echo "hi" Then on the target system (an Ubuntu system using ifupdown for configuration), I just configured eth0 fo…

Did you try if you can do something else beside the echo on Ubuntu? dhclient runs under an AppArmor profile which tries to keep it in a pretty short leash.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#104

Post by pyvpx »

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 :)

that would be one juicy target to compromise...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#105

Post by zorked »

Corrado wrote: post #98
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.

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 :/

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#106

Post by jnorthrop »

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?

That sounds like what Max Butler was busted for back in the late 1990's when he wrote a script to patch BIND[1]. It's a great story BTW.

http://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#107

Post by ams6110 »

laumars wrote: post #88
madaxe_again wrote: post #86

Earlier quoted context omitted.

While they sit there, oblivious to the fact that that router thing we use for the interwebs and all those IP cameras, NAS devices, and switches in their office are running linux, and bash, and are about to be used for industrial-grade extortion.

It's unlikely many consumer routers would be running Bash. They'd more likely have Busybox with the bog standard Bourne Shell. And same goes for most other embedded Linux devices too. Though I'm not suggesting that one shouldn't check their own devices to be safe rather than sure.

And how would one go about checking a typical Netgear home wireless router? The only way to manage it is http://192.168.1.1 right?

Or do they typically also offer some kind of shell (telnet? ssh?) access?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#108

Post by ams6110 »

hardwaresofton wrote: post #72
lbruder wrote: post #67

Earlier quoted context omitted.

While not exactly thrilled, as a Linux user I have to admit it's only fair. That's exactly what some of us did all those years when Windows used to have more holes than Linux. Ah well, back to BSD I guess...

Hmnn well I wonder just how much safer BSD is compared to Linux... I would consider linux to have more eyes on it, and if I remember correctly, LibreSSL was not infallible (despite all the shaming of OpenSSL folks that went on)

OpenBSD is actually formally reviewed/audited, not just relying on "many eyes." Of course you have to remember that only the base install is covered; software in packages/ports is not included in that.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#109

Post by lambda »

fulafel wrote: post #103
lambda wrote: post #40

Earlier quoted context omitted.

I reproduced it with dnsmasq as well; just set up a server with the following options. eth2 is the network adapter that I was using for the test network, and I picked the 10.0.10.0/24 prefix for this particular network. interface=eth2 dhcp-range=10.0.1.100,10.0.10.200,12h dhcp-option-force=114,() { :; }; echo "hi" Then on the target system (an Ubuntu system using ifupdown for configuration), I just configured eth0 fo…

Did you try if you can do something else beside the echo on Ubuntu? dhclient runs under an AppArmor profile which tries to keep it in a pretty short leash.

No, I didn't try that, but we happen to be running a custom kernel that doesn't include AppArmor support, as we needed to pull in a newer upstream kernel version. Given this issue, we should probably revisit that decision.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#110

Post by illumen »

Corrado wrote: post #98
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.

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

We should put pulseaudio in the init too. That never crashes.
Post reply on HN