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

141–150 of 160 posts

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#141

Post by Florin_Andrei »

neersighted wrote: post #118
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.

> It's the ultimate in vulnerabilities.

As someone who has survived the 1990's scare-a-palooza of Sendmail exploits, and ssh before separation of privileges, and on and on - no, it's not. Not even close.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#143

Post by dfc »

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

Earlier quoted context omitted.

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

Just so we are clear you would be talking about an unattended dist-upgrade from lenny to squeeze? Have you done this?

Please explain how your automated Debian administration system that has been in place since Lenny[^1] handles unattended dist-upgrades without the use of preseeding the debconf database for questions with a priority of high or critical?

[^1]: Squeeze was February 2011, any new stable installation since squeeze defaulted to dash as /bin/sh

EDIT: Nevermind, I answered my own question, unattended dist-upgrades from Lenny to squeeze is not something you have any experience with: "I'm now using Debian Wheezy, after primarily using Windows environments my entire life." https://news.ycombinator.com/item?id=6564610#up_6565766

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#144

Post by xorcist »

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.

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

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#145

Post by jude- »

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

You seem to be committing Systemd Logical Fallacy #12: "The Linux kernel is complex, and you use the Linux kernel, therefore you are okay with systemd being complex too"

Full list of fallacies: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#146

Post by andrewmunsell »

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

ReadyNAS (Netgear's NAS) uses dash by default, and bash can be upgraded to "4.2+dfsg-0.1+deb7u3"[1].

[1]: https://security-tracker.debian.org/tracker/CVE-2014-6271

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#147

Post by clarry »

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.

> That so many things delegate setting environment variables to the system shell

I think you've completely misunderstood the problem. The environment variable isn't and doesn't need to be set by a shell for shellshock to happen.

Why shouldn't a DHCP client pass server-originated data to a shell? Or any other program? There is nothing wrong with passing data. The only problem here is that a specific shell had a bug.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#148

Post by clarry »

hardwaresofton wrote: post #123
kibibu wrote: post #90

Earlier quoted context omitted.

> 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.

My point was that some OpenBSD guys rewrote OpenSSL in an attempt to fix it, yet also introduced some bugs (I read one article about a bug that was introduced by them, though I don't have a link, nor want to search the internet for it)... nvm, here's the link- http://www.theregister.co.uk/2014/07/17/libressl_crypto_bug/

They forked OpenSSL and inherited all its bugs.

And if you pay attention, you'll notice that this overblown bug was only relevant to Linux. Linux simply lacked some functionality OpenBSD has so they tried to hack a solution into the compatibility layer. So the first one or two preview releases turned out not to be perfect.

OpenBSD was never affected.

Though there were a few other unintended OS-agnostic changes that did actually slip in and were subsequently noticed and corrected.

Re: Shellshock DHCP Remote Code Execution – Proof of Concept

#149

Post by clarry »

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)

At least many of the things you find on OpenBSD really are much smaller and simpler than commonly used alternatives in the Linux land. Order-of-magnitude differences are common, but even 20k lines vs 60k lines means a lot if you're actually going to dive into the code.

So when I poke around under /usr/src, I find some utility or daemon or whatever else I haven't looked into before. And I think, oh, that's only a couple k lines of code? I wonder how it works... It just invites me to read.

I get the exact opposite reaction when faced with some system that's 200k lines of code. That looks important, maybe I should audit it.. nah, I don't have the time now. Maybe I'll start tomorrow. Tomorrow comes. Maybe I'll start in the weekend. Weekend comes. Maybe I'll start in two weeks because now I'm busy and next week I'm busy too. Two weeks later, chances are I don't even remember. If I do, I might end up promising myself to take a look at it around next Christmas...

Another thing is that OpenBSD moves slower, and instead of constantly adopting another cool new thing as the new replacement for the old thing that kinda worked but nobody wanted to improve, they seem to put more effort into extending and polishing the old thing that has served well. So there's less code churn, i.e. less new code with new bugs.

Post reply on HN