19 ms·

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 hund

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-the-machine)

ossreality 12y ago
lmao "embargo" seriously? How are there still people in every single one of these threads whining about responsible disclosure. The fact that they tried to "responsibly disclose" and "embargo" and THIS is what happened is proof of why not to even bother. So silly...
ams6110 12y ago
On the other hand Windows sysadmins are probably enjoying some schadenfreude right about now.
- lbruder 12y ago
  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...
  - hardwaresofton 12y ago
    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)
    - deleted 12y ago
      [deleted]
    - kibibu 12y ago
      > 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.
      - hardwaresofton 12y ago
        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/ http://www.theregister.co.uk/2014/07/17/libressl_crypto_bug/
        ZoFreX 12y ago
        They didn't rewrite it, they made changes to it - and they removed hundreds of bugs and potential bugs, on balance it's a huge improvement.
        clarry 12y ago
        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.
    - ams6110 12y ago
      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.
      - hardwaresofton 12y ago
        Oh I did not know that, that's cool
      - dllthomas 12y ago
        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.
    - clarry 12y ago
      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.
- takeda 12y ago
  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.
  - dfc 12y ago
    Debian's default /bin/sh is not "really bash," it is dash. The same is true for many embedded distros based on busybox.
    - mct 12y ago
      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.
      - dfc 12y ago
        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)? <Yes> <No>
        vertex-four 12y ago
        This assumes that the admin is administering their systems by running apt-get update && apt-get upgrade manually, rather than some automated process.
- pjmlp 12y ago
  I guess it is the hard way for some people to learn that they aren't safe just because they use UNIX systems vs Windows.
  - hardwaresofton 12y ago
    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 do, I'm sure they'll force a patch soon if they haven't already) and not even know there's a UNIX system down there
    - dfc 12y ago
      Redhat is "really a 'linux' company."
      - hardwaresofton 12y ago
        Ah sorry, I should have clarified, I should have qualified with "consumer facing"
- madaxe_again 12y ago
  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.
  - laumars 12y ago
    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.
    - rplnt 12y ago
      And "indusrial" routers are not running bash, or linux for that matter, either.
      - laumars 12y ago
        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.
        xorcist 12y ago
        Cisco is a big place. The Nexus series is Linux-based.
        buraglio 12y ago
        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.
Maxious 12y ago
"At present, public disclosure is scheduled for Wednesday, 2014-09-24 14:00 UTC. We do not expect the schedule to change, but we may be forced to revise it." http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650
neersighted 12y ago
It's the ultimate in vulnerabilities. Remote code execution over the network, potentially as root.
- Florin_Andrei 12y ago
  > 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.

ossreality 12y ago

lmao "embargo" seriously? How are there still people in every single one of these threads whining about responsible disclosure. The fact that they tried to "responsibly disclose" and "embargo" and THIS is what happened is proof of why not to even bother. So silly...

ams6110 12y ago

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

lbruder 12y ago
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...
- hardwaresofton 12y ago
  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)
  - deleted 12y ago
    [deleted]
  - kibibu 12y ago
    > 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.
    - hardwaresofton 12y ago
      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/ http://www.theregister.co.uk/2014/07/17/libressl_crypto_bug/
      - ZoFreX 12y ago
        They didn't rewrite it, they made changes to it - and they removed hundreds of bugs and potential bugs, on balance it's a huge improvement.
      - clarry 12y ago
        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.
  - ams6110 12y ago
    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.
    - hardwaresofton 12y ago
      Oh I did not know that, that's cool
    - dllthomas 12y ago
      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.
  - clarry 12y ago
    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.
takeda 12y ago
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.
- dfc 12y ago
  Debian's default /bin/sh is not "really bash," it is dash. The same is true for many embedded distros based on busybox.
  - mct 12y ago
    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.
    - dfc 12y ago
      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)? <Yes> <No>
      - vertex-four 12y ago
        This assumes that the admin is administering their systems by running apt-get update && apt-get upgrade manually, rather than some automated process.
pjmlp 12y ago
I guess it is the hard way for some people to learn that they aren't safe just because they use UNIX systems vs Windows.
- hardwaresofton 12y ago
  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 do, I'm sure they'll force a patch soon if they haven't already) and not even know there's a UNIX system down there
  - dfc 12y ago
    Redhat is "really a 'linux' company."
    - hardwaresofton 12y ago
      Ah sorry, I should have clarified, I should have qualified with "consumer facing"
madaxe_again 12y ago
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.
- laumars 12y ago
  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.
  - rplnt 12y ago
    And "indusrial" routers are not running bash, or linux for that matter, either.
    - laumars 12y ago
      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.
      - xorcist 12y ago
        Cisco is a big place. The Nexus series is Linux-based.
        buraglio 12y ago
        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.

Maxious 12y ago

"At present, public disclosure is scheduled for Wednesday, 2014-09-24 14:00 UTC. We do not expect the schedule to change, but we may be forced to revise it." http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650

neersighted 12y ago

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

Florin_Andrei 12y ago
> 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.