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

81–90 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#81

Post by noselasd »

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

You could probably exploit it via e.g. USB too. A lot of shell scripts get run when you plug in an USB device - And I'm sure you can cram the exploit into one of the device strings that the host queries for.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#82

Post by dfc »

jeffmcjunkin wrote: post #7
makomk wrote: post #4

Earlier quoted context omitted.

Thankfully embedded devices are less likely to have bash installed than desktop or server systems, or this would be quite nasty.

Very true. To be clear to other readers, busybox is more common in smaller embedded devices, though today's AlienVault blog post [1] showed that Mitel VoIP systems (which use Debian/ARM, if I recall) use bash and are vulnerable. [1] http://www.alienvault.com/open-threat-exchange/blog/attacker...

The default /bin/sh in Debian is dash.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#83

Post by mct »

dfc wrote: post #79
takeda wrote: post #69

Earlier quoted context omitted.

It's mostly Linux issue because bash is there installed by default and even /bin/sh is really bash... For example on BSD you could technically install bash, but chances that it is used as a shell for a services is very small.

Debian's default /bin/sh is not "really bash," it is dash. The same is true for many embedded distros based on busybox.

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.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#84

Post by dfc »

mct wrote: post #83
dfc wrote: post #79

Earlier quoted context omitted.

Debian's default /bin/sh is not "really bash," it is dash. The same is true for many embedded distros based on busybox.

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 presented with the following question:

  The system  shell is the default  command interpreter for 
  shell scripts.                                            
                                                
  Using  dash   as  the  system  shell   will  improve  the
  system's overall performance. It does not alter the shell
  presented to interactive users.   

  Use dash as the default system shell (/bin/sh)?

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#85

Post by hardwaresofton »

dfc wrote: post #80
hardwaresofton wrote: post #73

Earlier quoted context omitted.

Apple is just about the only company that really benefits from that misconception (possibly by virtue of the fact that there's not really a "linux" company, though Canonical is trying) I wonder if it would be a reach to say that the average mac user (though when I think about it, a disproportionate amount of those users are probably devs) will hear about this on the news, and assume Apple has their back (which they d…

Redhat is "really a 'linux' company."

Ah sorry, I should have clarified, I should have qualified with "consumer facing"

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#86

Post by madaxe_again »

ams6110 wrote: post #62
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-…

On the other hand Windows sysadmins are probably enjoying some schadenfreude right about now.

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.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#87

Post by justrandomanon »

bx_ wrote: post #78
iLoch wrote: post #32

I think one of the things Heartbleed PoCs did really well was show the result for the end user. Most people aren't going to know what any of this stuff means. Can we come up with a really straight forward explanation in laymans terms as to what this means for the average Internet user?

http://shellshock.co.za/ i thought this was pretty straightforward

offtopic

why do people use custom scrolling behaviour? it's always horrible

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#88

Post by laumars »

madaxe_again wrote: post #86
ams6110 wrote: post #62

Earlier quoted context omitted.

On the other hand Windows sysadmins are probably enjoying some schadenfreude right about now.

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.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#89

Post by ZoFreX »

lambda wrote: post #51
vibrolax wrote: post #31

FreeNAS (based on FreeBSD 9.2) has a vulnerable bash. I have 9.2.1.7.

The question is, does it call bash in its dhclient-script? I took a look through the FreeBSD source tree, and their version of dhclient-script uses /bin/sh. As long as /bin/sh is not bash (and that script doesn't in turn call any other bash scripts) it should be OK. The best way to find out if you're vulnerable is by testing. It takes just a few minutes to set up dnsmasq to serve up an exploit. Here were my settings:…

You can pretty much guarantee that nothing in the core system for FreeBSD calls Bash, because Bash isn't in the core system :)

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#90

Post by kibibu »

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)

> if I remember correctly, LibreSSL was not infallible

LibreSSL is a fork of OpenSSL - it would not be a huge surprise if there remained OpenSSL bugs in it.

Post reply on HN