# Shellshock - pkg upgrade bash



## alexus (Sep 26, 2014)

I'm using FreeBSD-9.1-p5.

My "security run output":


```
Checking for packages with security vulnerabilities:
Database fetched: Wed Sep 24 23:01:24 EDT 2014
bash-4.3.24
```
`pkg info bash`:

```
# 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`:

```
# 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?


----------



## aupanner (Sep 26, 2014)

I believe the fix is in 4.3.25.  Maybe tomorrow?


----------



## SirDice (Sep 26, 2014)

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


----------



## SirDice (Sep 26, 2014)

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.


----------



## kpa (Sep 26, 2014)

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.


----------



## gkontos (Sep 26, 2014)

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.


----------



## SirDice (Sep 26, 2014)

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.


----------



## hashime (Sep 26, 2014)

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.


----------



## kpa (Sep 26, 2014)

hashime said:
			
		

> SirDice said:
> 
> 
> 
> ...



Donate more money to the FreeBSD foundation and they can buy bigger and better hardware to build the packages more often.


----------



## SirDice (Sep 26, 2014)

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.


----------



## gkontos (Sep 26, 2014)

SirDice said:
			
		

> gkontos said:
> 
> 
> 
> ...



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.


----------



## hashime (Sep 26, 2014)

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.


----------



## SirDice (Sep 26, 2014)

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.


----------



## SirDice (Sep 26, 2014)

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.


----------



## hashime (Sep 26, 2014)

SirDice said:
			
		

> hashime said:
> 
> 
> 
> ...



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


----------



## SirDice (Sep 26, 2014)

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.


----------



## hashime (Sep 26, 2014)

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!


----------



## kpa (Sep 26, 2014)

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.


----------



## AzaShog (Sep 26, 2014)

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


```
#!/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....


----------



## talsamon (Sep 26, 2014)

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?


----------



## kpa (Sep 26, 2014)

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.


----------



## hashime (Sep 26, 2014)

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:

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


----------



## Juanitou (Sep 26, 2014)

I fail to see how a slow vendor server is an argument against FreeBSD ports.


----------



## hashime (Sep 26, 2014)

It's an argument for properly maintaining the FreeBSD's binary repositories.


----------



## mveety (Sep 26, 2014)

hashime said:
			
		

> It's an argument for properly maintaining the FreeBSD's binary repositories.


They are.


----------



## hashime (Sep 26, 2014)

mveety said:
			
		

> hashime said:
> 
> 
> 
> ...


No. Unless security does not matter for you at all.

Still no Bash update. Not even by now.


----------



## mveety (Sep 26, 2014)

hashime said:
			
		

> mveety said:
> 
> 
> 
> ...


Look, they're updated weekly. If you *NEED* the most bleeding edge code or some security update that isn't built yet then go with ports. We don't do things like the linux people. If you want to use BSD you need to get used to that fact. Binary packages are a luxury, you're not entitled to them.


----------



## AzaShog (Sep 26, 2014)

mveety said:
			
		

> Binary packages are a luxury, you're not entitled to them.



Wow, reading this in 2014 is... just.... wow!


----------



## gkontos (Sep 26, 2014)

@SirDice, you are right about the cgi scripts. Unfortunately, I have seen many control panel vendors doing exactly these things. In all matter, there was a big fuss about this bug, mainly caused by "experts" in the media.

Regarding the package delays. IMHO when we have a good package manager, like we finally do, we tend to become more lazy....  We also some times forget that this is a process that requires a lot of computing power and bandwidth. Since FreeBSD is really free and relies solely upon donations, there is no room for complains. New sysadmins need to get familiar with the ports system.


----------



## Juanitou (Sep 27, 2014)

AzaShog said:
			
		

> mveety said:
> 
> 
> 
> ...


What is “wow” is realising that people using a free OS developed by volunteers feel entitled to *something*. It’s better for me to stop here.


----------



## hashime (Sep 27, 2014)

mveety said:
			
		

> Look, they're updated weekly. If you *NEED* the most bleeding edge code or some security update that isn't built yet then go with ports. We don't do things like the linux people. If you want to use BSD you need to get used to that fact. Binary packages are a luxury, you're not entitled to them.



We are going in circles here.
If you mean with "we don't do things like the Linux people do" caring about security, well...
As stated earlier, if you provide binary packages without security updates in a timely manner someone should put a label on them "do not use on a internet connected machine, we don't care about security" The FreeBSD Handbook says nothing of the sorts, in the Handbook its a viable option, in the 10.0 Release notes it even says: pkg(7) is now the default package management utility.
*cough* default *cough*
When you look at the Handbook, installing binary packages comes before installing from ports. Anyhow, this is going in circles right back to the beginning of the thread.
Also there is no need to get all defensive and borderline aggressive about it, this is a big problem and it should be addressed.

There are 2 options here
a) discourage the use of binary packages or tell people that using FreeBSD's binary package system is highly insecure. Its 48h+ after the exploit hit and no security fix yet, that's clearly not OK. It is was Microsoft does. 
b) Building once a week is fine, but in cases of sever remote exploits rebuild the package in question ASAP. 

@gkontos
So are many Linux distributions, yet they have managed to distribute a proper bash binary within hours on every platform. Its fine if the binary package system is treated as a bastard child, but that needs to be communicated in the documentation.

Do it right, or don't do it at all. Doing it half leads to frustrated user and insecure FreeBSD boxes and i think no one likes that, that is something we can all agree on i hope?


----------



## talsamon (Sep 27, 2014)

Shellshock is a good name for this thread. I think over the time there are a lot of vulnerabilities (and some of them are more dangerous). And how many people really cares about? A well-known program like bash is a media-event. I still think it takes a blink of an eyes to compile it in the ports or make a own package. I ever think FreeBSD-users are more flexible.


----------



## AzaShog (Sep 27, 2014)

Juanitou said:
			
		

> What is “wow” is realising that people using a free OS developed by volunteers feel entitled to *something*. It’s better for me to stop here.



No, no, I do agree that people are not *entitled* to anything here, or any other project developed by unpaid volunteers. I was just wowing the attitude (not yours but in general reading something like that) about having binary packages. That they're a luxury. It just goes to show how relevant and important FreeBSD is in 2014. I'll stop now too.  :beergrin


----------



## Juanitou (Sep 27, 2014)

hashime said:
			
		

> Do it right, or don't do it at all. Doing it half leads to frustrated user and insecure FreeBSD boxes and i think no one likes that, that is something we can all agree on i hope?


Sorry, but I cannot agree: bash is not part of the FreeBSD OS. If it were, as recent history shows, you would have got a binary update through freebsd-update within hours. If a FreeBSD box is compromised today by third-party software, only the person managing it is to be blamed, waiting for somebody else to provide an updated binary package instead of using the port, which has been updated almost always by some unpaid volunteer. Sure, quickly providing security updates for packages of third-party software would be nice, but with the limited resources of the FreeBSD environment it seems not possible right now. Let’s donate some money, time or knowledge to try to improve this.

Sincerely, I think the problem lies in that you are approaching a non-issue wrongly and, sure enough, this can only lead to bad conclusions and frustration.


----------



## jb_fvwm2 (Sep 27, 2014)

*Hmmm*

Hmmm...   (The following is an informed (I hope)  suggestion, not a criticism which is how it might read otherwise)

FRI  all ports built. pull pkg, pkg-devel out. Do they segfault? Put them back in.
FRI  pull chromium out. Does it segfault? Put it back in.
FRI  Make repo avail publicly
TUE  bash vulnerability.  Pull it out. Rebuild. Put it back in

...
...

...As  something into the mix, to add, which could be helpful.


----------



## kpa (Sep 27, 2014)

Here's some hard stats for people who still try make this such a big issue. The amount of ports that require shells/bash at run time is a whopping 157 out of the total 24000+ ports that are in the tree. Build time dependencies are not an issue because the build environment is going to be quite clean and will not inherit anything from user's environment to the point where bash gets actually run.

Very few of the run time dependents are among the most popular FreeBSD ports as far as I can see. The full list can be found at http://www.freshports.org/shells/bash/, scroll down to the "This port is required by" and "for Run".

To people who are going to say that they absolutely need to use shells/bash you have my sympathy.


----------



## gkontos (Sep 27, 2014)

Everybody knows here that I have shifted most of may servers to CentOS. (At least the old crew). 

Regarding, shellshock bug though. I must admit that the most professional approach to the problem came from the FreeBSD community.


----------



## stefanlasiewski (Sep 28, 2014)

Is the Bash binary package tested before it is deposited to the Package servers, or are customers expected to do their own testing before rolling it out to all of our servers?

I see the post Ports Tree Now Fully Staged which talks a bit about a testing framework, but I can't find more customer-facing information about this testing framework.

Thanks,

-= Stefan


----------



## stefanlasiewski (Sep 28, 2014)

> There are 2 options here
> a) discourage the use of binary packages or tell people that using FreeBSD's binary package system is highly insecure. Its 48h+ after the exploit hit and no security fix yet, that's clearly not OK. It is was Microsoft does.
> b) Building once a week is fine, but in cases of sever remote exploits rebuild the package in question ASAP.



Arguably,  the third option is that the authoritative documentation, like the FreeBSD Handbook, should set proper expectations for the business customers. Be clear about the once-per-week schedule, be clear that this same schedule applies to critical vulnerabilities and that customers should be expected to build from source or compile their own packages using something like poudriere. "If you use FreeBSD in the enterprise for more then a few systems, we strongly encourage that you set up your own binary package server using poudriere." or something similar.

Keep in mind folks, Shellshock isn't simply a media event, it was also a management edict. Every security authority out there, like CERT & the DHS, said "PATCH BASH. NOW." and most organizations have a contractual obligation with their customers which says "We will address all security issues and provide timely updates to our systems. Exceptions will be rare."

Just about every sysadmin on the planet was required to batch Bash as soon as possible. We don't have the luxury to say "You know what? CERT is wrong when they have this a 10/10 rating. I think it's not that critical." Sysadmins worked late nights, long days and on the weekend to get this patched. Usually, we can't just uninstall bash because our tools and customers might depend on it.


----------



## phoenix (Sep 30, 2014)

alexus said:
			
		

> I'm using FreeBSD-9.1-p5.
> 
> `pkg upgrade bash`:



That command is incorrect.  The correct command is `pkg install bash`

`pkg upgrade` is used to upgrade *all* installed packages, not single packages.


----------



## stefanlasiewski (Sep 30, 2014)

> pkg upgrade is used to upgrade all installed packages, not single packages.



Are you sure? The man page says it can be used to update 'specific' packages? At least that's how I read their meaning of 'pkg-name' and 'specific packages'.



> pkg upgrade [--{force,no-install-scripts,dry-run,fetch-only}]
> [--{quiet,no-repo-update,yes}] [--repository reponame]
> [--{case-sensitive,glob,case-insensitive,regex}]
> [<pkg-origin|pkg-name|pkg-name-version> ...]
> ...



In addition, `pkg upgrade bash` seems to work just fine, and `pkg upgrade someotherpackage` installed that package, and a dependencies or two.


----------



## drhowarddrfine (Sep 30, 2014)

Since packages are just compiled ports, what's wrong with making your own package and use that?


----------



## junovitch@ (Sep 30, 2014)

phoenix said:
			
		

> That command is incorrect.  The correct command is `pkg install bash`
> 
> `pkg upgrade` is used to upgrade *all* installed packages, not single packages.



Actually it's a new feature with 1.3.x.  Before you would have had to do a `pkg install bash` which would have only upgraded bash and is a bit counter-intuitive.


----------



## teo (Oct 1, 2014)

Not worth Bash,  is vulnerabilitie, in days past security experts were saying to the press the danger of using Bash.


----------



## scottro (Oct 1, 2014)

@@junovitch thank you.  I hadn't realized that one can now use `pkg upgrade` on a specific package.


----------



## stefanlasiewski (Oct 1, 2014)

Since `pkg upgrade` seems to work fine for a single package, does that mean that FreeBSD bug #334: pkg upgrade cannot upgrade a single package is no longer accurate?


----------



## phoenix (Oct 1, 2014)

junovitch said:
			
		

> phoenix said:
> 
> 
> 
> ...



Ah, good to know.  I was reading a 1.2.x man page.  Only just upgraded to 1.3.x today.


----------



## frijsdijk (Oct 2, 2014)

I think it's unacceptable that updates are only run once a week. What could we do to speed this up?


----------



## SirDice (Oct 2, 2014)

Donate more hardware.


----------



## frijsdijk (Oct 2, 2014)

Some additional questions:

- Is hardware shortage the only factor?
- Could this donation be in the form of providing the infrastructure in our own network, in stead of providing a donation in the form of money to the FreeBSD organisation?

And in this case (bash of course), with such a serious bug, and the fact that bash as very few dependencies, why not provide an update for bash itself in a shorter term than one a week, in stead of building the complete ports-tree (assuming that that's the case).


----------



## hashime (Oct 2, 2014)

frijsdijk said:
			
		

> I think it's unacceptable that updates are only run once a week. What could we do to speed this up?



That's not exactly true, is it? pkg upgrade came on the weekend, I think, and another package got upgraded before Wednesday as well.
So if we are able to upgrade pkg for some reason, we should be able to upgrade one of the most sever security bugs in this decade asap too.

Anyhow, one can draw his/her own conclusion about how the bash bug was handled in regards to the FreeBSD binary package system and how FreeBSD treats security risks.

I for one switched to ports :-(. (and back to Debian on a low power machine)


----------

