Shellshock - pkg upgrade bash

I'm using FreeBSD-9.1-p5.

My "security run output":

Code:
Checking for packages with security vulnerabilities:
Database fetched: Wed Sep 24 23:01:24 EDT 2014
bash-4.3.24
pkg info bash:
Code:
    # pkg info bash
    bash-4.3.24
    Name           : bash
    Version        : 4.3.24
    Installed on   : Tue Sep 16 17:17:32 EDT 2014
    Origin         : shells/bash
    Architecture   : freebsd:9:x86:64
    Prefix         : /usr/local
    Categories     : shells
    Licenses       : GPLv3
    Maintainer     : ehaupt@FreeBSD.org
    WWW            : http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
    Comment        : The GNU Project's Bourne Again SHell
    Options        :
    	COLONBREAKSWORDS: on
    	DOCS           : on
    	HELP           : on
    	IMPLICITCD     : on
    	NLS            : on
    	STATIC         : off
    	SYSLOG         : off
    Shared Libs required:
    	libintl.so.9
    	libiconv.so.3
    Annotations    :
    	repo_type      : binary
    	repository     : FreeBSD
    Flat size      : 6.65MiB
    Description    :
    This is GNU Bash.  Bash is the GNU Project's Bourne Again SHell,
    a complete implementation of the POSIX.2 shell spec, but also
    with interactive command line editing, job control on architectures
    that support it, csh-like features such as history substitution and
    brace expansion, and a slew of other features. 
    
    WWW: http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
    #
pkg upgrade bash:
Code:
    # pkg upgrade bash 
    Updating FreeBSD repository catalogue...
    FreeBSD repository is up-to-date.
    All repositories are up-to-date.
    Checking integrity... done (0 conflicting)
    Your packages are up to date.
    #

Am I doing something wrong or does it mean maintainer didn't update package yet security vulnerabilities list is up to date?
 
Packages are updated once a week. As far as I know this happens every Wednesday so the last run may just have missed it.
 
Also keep in mind that the apparently huge vulnerability isn't that huge at all. It's very unlikely you will be bitten by this bug.
 
SirDice said:
Also keep in mind that the apparently huge vulnerability isn't that huge at all. It's very unlikely you will be bitten by this bug.

Yeah I've been scratching my head about how this is any different from PHP security bugs that first require the ability to inject some arbitrary code to the server to be executed. The vulnerability is bad but if exploiting it requires that the attacker can change the running environment first it's kind of academic. The real vulnerability then becomes the ability to inject arbitrary code to the execution path of a server thread, not what the interpreter be it BASH or PHP does wrong.

Moral of the lesson: Sanitize the #%&%&#€%#%€# input before evaluating it as part of your code.
 
The issue got a lot of publicity so everyone is in panic. I have patched more than 30 servers so far. I also successfully managed to exploit a few servers that I manage running CentOS but none running FreeBSD, even if they had bash installed.

The main problem here is that the exploit is very easy to be performed.
 
gkontos said:
I also successfully managed to exploit a few servers that I manage running CentOS {...}
I'm wondering how exactly?

The only ways I can come up with either require a shell injection vulnerability in a website or requires a local account. The first is a non-issue because they can already inject shell code and thus won't need to use this. And because the site has a shell injection vulnerability there's already a big hole, this won't make it bigger. The same for the people with shell access, they can already do whatever they want. The trick only seems to be of any benefit if you allow shell access but have it limited with ForceCommand. In that case somebody would be able to inject extra code.

Running a shell CGI script is of course dangerous, but that was the case even without shell-shock.
 
SirDice said:
Packages are updated once a week. As far as I know this happens every Wednesday so the last run may just have missed it.

This is really really careless and scary.
Goes to show how FreeBSD treats binary packages and security in binary packages. Basically makes it unusable.
Why provide it at all then if no updates are provided at a sever security hole?

Really disappointing.
 
hashime said:
SirDice said:
Packages are updated once a week. As far as I know this happens every Wednesday so the last run may just have missed it.

This is really really careless and scary.
Goes to show how FreeBSD treats binary packages and security in binary packages. Basically makes it unusable.
Why provide it at all then if no updates are provided at a sever security hole?

Really disappointing.

Donate more money to the FreeBSD foundation and they can buy bigger and better hardware to build the packages more often.
 
hashime said:
Why provide it at all then if no updates are provided at a sever security hole?
Ports have it and most of us run their own repositories.

The reason it's only done once a week is due to the limited resources. Unless somebody donates a bunch of hardware it's unlikely to change.
 
SirDice said:
gkontos said:
I also successfully managed to exploit a few servers that I manage running CentOS {...}
I'm wondering how exactly?

The only ways I can come up with either require a shell injection vulnerability in a website or requires a local account. The first is a non-issue because they can already inject shell code and thus won't need to use this. And because the site has a shell injection vulnerability there's already a big hole, this won't make it bigger. The same for the people with shell access, they can already do whatever they want. The trick only seems to be of any benefit if you allow shell access but have it limited with ForceCommand. In that case somebody would be able to inject extra code.

Running a shell CGI script is of course dangerous, but that was the case even without shell-shock.

It actually requires an application that uses bash. Of course you need to do some digging. In all cases I created a small script, placed in cgi-bin. I also sent you a pm with a site that during my research, I managed to get the /etc/passwd file.
 
I understand that, but in case of sever security flaws, like the bash one, an updated binary must be provided at once, otherwise providing binary packages at all is careless at best. Does not matter what "most of us" use.
I understand where you are coming from, but the bash example shows how FreeBSDs binary package system falls short in comparison to *any* other Linux package System.

Anyhow, I took that as an excuse to switch over to ports as its clear how pkg is not suitable for servers connected to the internet.
 
hashime said:
Anyhow, i took that as an excuse to switch over to ports as its clear how pkg is not suitable for servers connected to the internet.
If you have more than one server to maintain I can highly recommend setting up your own repository. That will give you the benefits of both ports and packages.
 
gkontos said:
In all cases I created a small script, placed in cgi-bin.
Which is a bad idea to begin with, regardless of this bug. I'm sure in this case it's easily exploited but it was a bad setup to begin with. Like I said, using a CGI shell script is a bad idea and should be avoided at all costs.
 
SirDice said:
hashime said:
Anyhow, i took that as an excuse to switch over to ports as its clear how pkg is not suitable for servers connected to the internet.
If you have more than one server to maintain I can highly recommend setting up your own repository. That will give you the benefits of both ports and packages.

Sure, but unless I have to apply local patches or have a lot of machines, there is no upside to it. Just more work. But I guess that discussion is a bit off topic and i am sure has been held many times on these forums ;)
 
hashime said:
Sure, but unless I have to apply local patches or have a lot of machines, there is no upside to it.
Build once, install many ;)

Just more work.
Not if set up properly. In the morning I just fire off a poudriere run with a simple command and an hour later all my packages (about 250 of them) are built and ready to go. There's very little actual work as the process does everything automatically.
 
SirDice said:
Build once, install many

Sure, but that is what binary repositories are there for. If you have bandwidth issues you can always mirror it, or the needed packages. If the binary repo was done right.

SirDice said:
Not if set up properly. In the morning I just fire off a poudriere run with a simple command and an hour later all my packages (about 250 of them) are built and ready to go. There's very little actual work as the process does everything automatically.

So, more work then, just not much more. Ok. And you need a powerful CPU, so probably and extra server, extra space, extra power, extra admin time.
Which is fine and ok in a big-ish company, but if you just manage a few boxes, or a single one that is so much overhead for no benefit at all.
It's even worse in a heterogeneous environment. Imagine i386, amd64, maybe 9.X and 10.X. Maybe some other BSDs or Linuxes. Thats alot of build time.
Hey, vim alone with all its dependencies takes 30 min on this local corei3.


Fact is, it's the Year 2014 and FreeBSD's binary repository does not offer security fixes in a timely manner. This is sad and should be looked at. Or come with a warning not to connect FreeBSD machines to the internet.
This is serious.
Even my Raspberry pi has an updated bash meanwhile. The pi! yet FreeBSD does not manage to? Come on!
 
You want to know what the (semi)official response would have been before PKGNG packages? "Use the ports dude, that's what everyone else is using". You are just not aware of the history of binary packages in FreeBSD. Before PKGNG packages you were very lucky if you could keep your system up to date with the official old style binary packages, they were really that bad. Practically everyone who took using FreeBSD serious was building their own ports and didn't pay any attention to the binary packages other than for quick bootstrapping a new system.
 
SirDice said:
Running a shell CGI script is of course dangerous, but that was the case even without shell-shock.

True, and unfortunately there's a LOT of Apache servers out there configured to allow CGI. Pretty much all cPanel servers. Now, it is true that it is 2014 and pretty much vast majority of software has moved from being cgi-bin Perl scripts to FastCGI/WSGI powered PHP/Perl/Python/Ruby/whatever.

I maintain some cPanel servers for some clients, and I have had the "pleasure" to witness this gem when migrating accounts in from other cPanel hosts. It is apparently used by some hosting companies to launch custom interpreters for custom php.ini directives. Yes, it's a shell script placed in cgi-bin of the account (keep in mind that on CentOS, where cPanel reigns, /bin/sh symlinks to bash):

Code:
#!/bin/sh
export PHP_FCGI_CHILDREN=1
export PHP_FCGI_MAX_REQUESTS=10
exec /usr/local/cpanel/cgi-sys/php5

Now, that's one hell of a perfect (in)security storm: Apache allowing CGI + cPanel + PHP + shell launchers....
 
Some things I dont't really understand. If I work with the port - bash is not a really big program - it's compiled in three minutes - will this be a problem? Is there any need for a binary?
 
talsamon said:
Some things I dont't really understand. If I work with the port - bash is not a really big program - it's compiled in three minutes - will this be a problem? Is there any need for a binary?

Some people would prefer to use just binary packages, for example in very low power platforms where compiling ports is not an option. We are not quite there yet as witnessed by this thread among others.
 
talsamon said:
Some things I dont't really understand. If I work with the port - bash is not a really big program - it's compiled in three minutes - will this be a problem? Is there any need for a binary?


Another reason why the ports system is vastly inferior to a properly setup binary repository system, for most use-cases, is stuff like this:
Code:
=> cups-1.7.3-source.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch http://www.cups.org/software/1.7.3/cups-1.7.3-source.tar.bz2
cups-1.7.3-source.tar.bz2                      72% of 8586 kB 9518  Bps 04m36s

That's right, that's not even 1kbyte/sec and i am sitting on a 150mbit line in the middle of Europe in a very well connected country.
What takes on, lets say Debian on a same country or same continent mirror, a few seconds takes on FreeBSD, using the ports system, many many minutes or even hours.
That is one of the reasons why it is so important to have a well maintained binary package system.
 
Back
Top