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

151–160 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#151

Post by SixSigma »

dllthomas wrote: post #136
SixSigma wrote: post #132

Earlier quoted context omitted.

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.

We totally disagree. The ad-hoc nature of unplanned and ill disciplined thrashing away at readline is a terrible interface.

Dave Presotto put it best "Linux: by amateurs, for amateurs"

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#152

Post by dllthomas »

SixSigma wrote: post #151
dllthomas wrote: post #136

Earlier quoted context omitted.

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.

We totally disagree. The ad-hoc nature of unplanned and ill disciplined thrashing away at readline is a terrible interface. Dave Presotto put it best "Linux: by amateurs, for amateurs"

Apparently we disagree. My interaction with a readline interface in a context I understand is neither unplanned nor ill disciplined. You can throw around pejoratives, but clearly you cannot support them.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#153

Post by rsmarples »

dhcpcd-6.4.7 is hot off the press, the main improvement being mitigating the bash "ShellShock" exploit by escaping all characters as noted in IEEE Std 1003.1, 2004 Edition, 2. Shell Command Language, 2.2 Quoting except for the space character.

Needless to say, the entire BSD family is not affected by this bug as bash is not the default shell and to be fair a lot of Linux distributions are not affected either. If bash is your Linux distributions /bin/sh, OR you have applications directly calling bash, you should be telling them to get with the times as most people have since moved on to ash, dash or busybox for more efficient processing.

Regardless, shell is such an important in part of the system - it allows non programmers to "do things". Thanks to the dhcpcd hook system, a user was able to start tcpdump on hotplugged interface before dhcpcd actually started using it during the boot process. Why he wanted to do this, I don't know, probably for some debugging. But the point is, how would he have done this without shell hooks?

The important thing to take away from this is don't lock yourself into one technology - strive to be portable. dhcpcd works on many OS's, libcs, shells and userland tools. If any of them prove faulty, swap them out - including dhcpcd itself! But please at least tell me why you're swapping dhcpcd out so I can improve it :)

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#154

Post by SixSigma »

1wd wrote: post #124
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

Maybe we need a catchy name for this "anti-pattern".

we do : GNU

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#155

Post by sploitfun »

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.

Nope dhclient running under apparmor profile is still vulnerable. I was able to execute linux commands like rm, wget, chmod...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#156

Post by internut »

laumars wrote: post #94
rplnt wrote: post #91

Earlier quoted context omitted.

And "indusrial" routers are not running bash, or linux for that matter, either.

Depends on the router. Cisco is famously runs IOS, which I believe is based on BSD (FreeBSD 2.2 specifically). Barracuda gear, however, is Linux based. However in all cases, I think you'd still be right about Bash not being present.

IOS is completely home rolled. IOS-XR is now Linux based.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#157

Post by laumars »

internut wrote: post #156
laumars wrote: post #94

Earlier quoted context omitted.

Depends on the router. Cisco is famously runs IOS, which I believe is based on BSD (FreeBSD 2.2 specifically). Barracuda gear, however, is Linux based. However in all cases, I think you'd still be right about Bash not being present.

IOS is completely home rolled. IOS-XR is now Linux based.

IOS XR used to be QNX though, if I'm not mistaken?

I hadn't heard of these other Cisco products until yesterday, but from what I read IOS XE and NX OS also run on Linux.

Anyhow, getting back to my original point about FreeBSD, there's a few sources that have linked IOS to FreeBSD. But after doing some digging of my own on this topic, I've come to the conclusion that this is one of those urban legends that's proliferated for whatever reason. So it would seem that you're right about IOS being home rolled. Interestingly though, they do have other products which are FreeBSD powered (eg AsyncOS http://www.cisco.com/c/en/us/products/security/email-securit...) but, as you said, not IOS

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#158

Post by fulafel »

sploitfun wrote: post #155
fulafel wrote: post #103

Earlier quoted context omitted.

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.

Nope dhclient running under apparmor profile is still vulnerable. I was able to execute linux commands like rm, wget, chmod...

Interesting! Hopefully someone will post an investigation on what goes wrong in AppArmor here.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#159

Post by buraglio »

xorcist wrote: post #144
laumars wrote: post #94

Earlier quoted context omitted.

Depends on the router. Cisco is famously runs IOS, which I believe is based on BSD (FreeBSD 2.2 specifically). Barracuda gear, however, is Linux based. However in all cases, I think you'd still be right about Bash not being present.

Cisco is a big place. The Nexus series is Linux-based.

IOS-XE and XR are linux boxes, as are the nexus. Arista is linux based, Juniper is FreeBSD and Force10 is NetBSD (at least the older one were). Many devices in the class of enterprise or service provider grade are not going to be obtaining their addresses via DHCP and have a heavily modified version of the OS, anyway. In addition, best practices should be used in armoring the devices in this class, meaning filtering of the control plane, etc.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#160

Post by dllthomas »

ams6110 wrote: post #108
hardwaresofton wrote: post #72

Earlier quoted context omitted.

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.

It bugs me a bit that "many eyes" took on a security connotation to begin with. That doesn't seem to have been the original claim - it didn't strike me as such when I originally read CatB, and revisiting I can see a way to give it a strong reading but it still doesn't seem to be the sense intended. "Many eyes" in the sense I read it starts once someone notices that there is a bug - for which audit is tremendously better suited than use or casual perusal when it comes to security issues.
Post reply on HN