Hacker News Reader

Comment by ams6110 | Hacker News Reader

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

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.

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>

This assumes that the admin is administering their systems by running apt-get update && apt-get upgrade manually, rather than some automated process.

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

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

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.

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

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?

Some Netgears do offer telnet, though you often need to enable it via a "magic packet" hack. If you Google your router model number and "telnet" then there should be more information on whether your product supports this and how to go about enabling.

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.

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

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.

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.

Oh I did not know that, that's cool

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.

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.

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.

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

Redhat is "really a 'linux' company."

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

Reply on news.ycombinator.com