Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
Remote exploit vulnerability in bash
- micksulley
- Posts: 61
- Joined: 2012-09-06 12:20
Re: Remote exploit vulnerability in bash
Many thanks. I added the security repo's updated and now my Bash is secure again!
Regarding the earlier comments about my lack of understanding or sources, if anyone can point me to something that explains what you should have and why, I would certainly study it. The links posted earlier do nothing to tell you which ones you need, rules on mixing them, the fact that you should add the security repro, which ones contain which packages etc. I really have tried to unserstand this in the past, it seems that the people who know 'just know', there does not seem to be any useful tutorial on this subject.
Again, thanks for helping me to fix it.
Mick
Regarding the earlier comments about my lack of understanding or sources, if anyone can point me to something that explains what you should have and why, I would certainly study it. The links posted earlier do nothing to tell you which ones you need, rules on mixing them, the fact that you should add the security repro, which ones contain which packages etc. I really have tried to unserstand this in the past, it seems that the people who know 'just know', there does not seem to be any useful tutorial on this subject.
Again, thanks for helping me to fix it.
Mick
Re: Remote exploit vulnerability in bash
All this is off topic but, since you ask: Providing the network gets configured during installation, which is not always the case when non-free drivers are required, then apt is properly configured with all the necessary software sources including security. Manually editing /etc/apt/sources.list/ is a little tricky; the sources.list man page explains it in detail but of course, an appropriate mirror site needs to be inserted. With regard to both stability and security, following basic precautions, neither mixing different suites nor adding potentially untrusted software sources, like, for example, deb-multimedia, is recommended as advised here. Finally, for best security, a stable system without admixture of software that doesn't comply with DFSG is to be recommended as detailed here.
DebianStable
Code: Select all
$ vrms
No non-free or contrib packages installed on debian! rms would be proud.
Re: Remote exploit vulnerability in bash
When searching online, always google 'debian wiki whatever_subject' and usually you'll find something. It has a good Wheezy example:
https://wiki.debian.org/SourcesList
If you're still unsure you can repost your sources.list for review.
https://wiki.debian.org/SourcesList
If you're still unsure you can repost your sources.list for review.
800mhz, 512mb ram, dCore-jessie (Tiny Core with Debian Jessie packages) with BusyBox and Fluxbox.
Most don't have computer access, reuse or pay forward an old computer.
Most don't have computer access, reuse or pay forward an old computer.
Re: Remote exploit vulnerability in bash
Just thought I would say that this is what I used to make bash not vulnerable, as far as I know:
apt-get update && apt-get install --only-upgrade bash
apt-get update && apt-get install --only-upgrade bash
- micksulley
- Posts: 61
- Joined: 2012-09-06 12:20
Re: Remote exploit vulnerability in bash
That only worked for me after I had added the security repoOhm wrote:Just thought I would say that this is what I used to make bash not vulnerable, as far as I know:
apt-get update && apt-get install --only-upgrade bash
Re: Remote exploit vulnerability in bash
Yes, the security repo is is necessary for security updates. (I wonder if that has anything to do with why they call it the "security" repo?)
Re: Remote exploit vulnerability in bash
I happen to have been reinstalling debian yesterday anyway, and after installing the base debian system - without any tasks or standard utilities selected - bash is installed and listed as manually installed (i.e. not installed because it is depended upon or recommended by another installed package). It's also listed as being an "important" package, despite (on this barebones operating system) not having any installed packages dependent on it.
As people have been reminding one another lately, debian moved away from bash a very long time ago, and now uses dash (whatever that means in practice, since the consoles on most desktops that I've seen tend to use bash by default). So, one might think it safe to remove bash, and just use dash for my command line work. This I did, just as an experiment, with no immediate effect. At reboot, all went well until login. Here, running the login details merely took me back to login again, whether I logged in as root or a standard user.
Suffice to say, you can reinstall bash in "single user" recovery mode, but I'm thinking that something probably very simple would have done the job of safely removing bash whilst no affecting the system, but only super brains who cast scorn at the miserable frightened herd are capable of working it out, and if I asked for help here I'd run the risk of being named and shamed by my superiors as just another hijacker...
One other thought, for those who haven't browsed away somewhere else: According to the latest popularity contest, bash is listed at number 30 on installs, and number 32 on actually used packages, so clearly the move from bash to dash wasn't as complete as some might think.
As people have been reminding one another lately, debian moved away from bash a very long time ago, and now uses dash (whatever that means in practice, since the consoles on most desktops that I've seen tend to use bash by default). So, one might think it safe to remove bash, and just use dash for my command line work. This I did, just as an experiment, with no immediate effect. At reboot, all went well until login. Here, running the login details merely took me back to login again, whether I logged in as root or a standard user.
Suffice to say, you can reinstall bash in "single user" recovery mode, but I'm thinking that something probably very simple would have done the job of safely removing bash whilst no affecting the system, but only super brains who cast scorn at the miserable frightened herd are capable of working it out, and if I asked for help here I'd run the risk of being named and shamed by my superiors as just another hijacker...
One other thought, for those who haven't browsed away somewhere else: According to the latest popularity contest, bash is listed at number 30 on installs, and number 32 on actually used packages, so clearly the move from bash to dash wasn't as complete as some might think.
Perfectionism is an imperfection
Re: Remote exploit vulnerability in bash
Thanks for the tip. After reading this, I promptly upgraded bash on this machine - Wheezy 7.6 - and will do so on the others upon next power-up.
Have not read through all the external links in this thread, but I bet the linux haters are cackling with glee. But thanks to the Debian maintainers, it seems the fix(es?) was or were done very quickly.
tex
Have not read through all the external links in this thread, but I bet the linux haters are cackling with glee. But thanks to the Debian maintainers, it seems the fix(es?) was or were done very quickly.
tex
Re: Remote exploit vulnerability in bash
How to Protect your Server Against the Shellshock Bash Vulnerability:
https://www.digitalocean.com/community/ ... nerability
The article recommends running the following in a bash terminal:
https://www.digitalocean.com/community/ ... nerability
The article recommends running the following in a bash terminal:
Code: Select all
env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"
My old Squeeze-based Ubuntu received 3 bash updates between Sept 24th-29th. It now passes the bash test and just returns 'Bash Test'The highlighted echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:
Bash is vulnerable!
Bash Test
Otherwise, if your output does not include the simulated attacker's payload, i.e. "Bash is vulnerable" is not printed as output, your version of bash is not vulnerable. It may look something like this:
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test
800mhz, 512mb ram, dCore-jessie (Tiny Core with Debian Jessie packages) with BusyBox and Fluxbox.
Most don't have computer access, reuse or pay forward an old computer.
Most don't have computer access, reuse or pay forward an old computer.
Re: Remote exploit vulnerability in bash
Many thanks, mardybear, for this useful command. It's nice to get Bash Test
- Hallvor
- Global Moderator
- Posts: 2029
- Joined: 2009-04-16 18:35
- Location: Kristiansand, Norway
- Has thanked: 139 times
- Been thanked: 206 times
Re: Remote exploit vulnerability in bash
It looks like many people are looking at the code at the moment. Problems get fixed. I think that is a good thing.
Edit: Another bash upgrade today.
[HowTo] Install and configure Debian bookworm
Debian 12 | KDE Plasma | ThinkPad T440s | 4 × Intel® Core™ i7-4600U CPU @ 2.10GHz | 12 GiB RAM | Mesa Intel® HD Graphics 4400 | 1 TB SSD
Debian 12 | KDE Plasma | ThinkPad T440s | 4 × Intel® Core™ i7-4600U CPU @ 2.10GHz | 12 GiB RAM | Mesa Intel® HD Graphics 4400 | 1 TB SSD
Re: Remote exploit vulnerability in bash
Agreed. It's still worrisome (at least to me) that the vulnerabilities are as deep as they seem to be. And the continuing proliferation of not-really-a-fix "fixes" means that the number of folks who think it's fixed when it really isn't is growing.Hallvor wrote:It looks like many people are looking at the code at the moment. Problems get fixed. I think that is a good thing.
Re: Remote exploit vulnerability in bash
I guess count me among those who thought it was fixed... Will have to keep my ear to the ground on this one.dasein wrote:Agreed. It's still worrisome (at least to me) that the vulnerabilities are as deep as they seem to be. And the continuing proliferation of not-really-a-fix "fixes" means that the number of folks who think it's fixed when it really isn't is growing.Hallvor wrote:It looks like many people are looking at the code at the moment. Problems get fixed. I think that is a good thing.
It is worrisome, but I'd still rather be running Debian linux over Windows any day. Don't know diddly about dash, but I guess that's an option.
tex
Re: Remote exploit vulnerability in bash
I saw on debian-devel that Ian Jackson had proposed removing the ability for bash to functions from the environment. That would remove the entire class of vulnerability, at a cost of killing a feature that it seems like few people use, though I have no real data on that last. Using `bash -p` has a similar effect.
dash can't import functions from the environment AFAIK. It lacks a lot of bash's features (like history and completion) so it isn't a good choice for an interactive shell (at least not for me) but is good for your shell scripts as long as they don't rely on bashisms.
dash can't import functions from the environment AFAIK. It lacks a lot of bash's features (like history and completion) so it isn't a good choice for an interactive shell (at least not for me) but is good for your shell scripts as long as they don't rely on bashisms.
Re: Remote exploit vulnerability in bash
The bash shellshock problem appears to have been fixed in wheezy and squeeze i386.
The debian squeeze armel version is commonly used in NAS boxes and network drives. It appears to install dash by default if it matters.
I'm using a TonidoPlug2, when I run sudo aptitude update
it displays lines like this:
Hit http://security.debian.org squeeze/updates/main armel Packages
When I run sudo aptitude upgrade
it doesn't update bash.
~# cat /etc/issue
Debian GNU/Linux 6.0 \n \l
~# cat /etc/debian_version
6.0.10
~# cat /proc/version
Linux version 2.6.31.8-topkick1281p2-001-004-20101214 (andrew@localhost.localdomain) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #1 Thu Jun 16 10:06:20 CST 2011
Can we have the squeeze armel version patched as well.
The debian squeeze armel version is commonly used in NAS boxes and network drives. It appears to install dash by default if it matters.
I'm using a TonidoPlug2, when I run sudo aptitude update
it displays lines like this:
Hit http://security.debian.org squeeze/updates/main armel Packages
When I run sudo aptitude upgrade
it doesn't update bash.
~# cat /etc/issue
Debian GNU/Linux 6.0 \n \l
~# cat /etc/debian_version
6.0.10
~# cat /proc/version
Linux version 2.6.31.8-topkick1281p2-001-004-20101214 (andrew@localhost.localdomain) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #1 Thu Jun 16 10:06:20 CST 2011
Can we have the squeeze armel version patched as well.
- dilberts_left_nut
- Administrator
- Posts: 5346
- Joined: 2009-10-05 07:54
- Location: enzed
- Has thanked: 12 times
- Been thanked: 66 times
Re: Remote exploit vulnerability in bash
Squeeze is EOL so won't be getting any (official) updates.
AFAIK squeeze-lts is i386/amd64 only.
AFAIK squeeze-lts is i386/amd64 only.
AdrianTM wrote:There's no hacker in my grandma...