Shellshock vulnerability

[wimr]

I tested bash in NAS4Free and it is vulnerable for Shellshock. Can you give an update on when we can expect a patch for this serious issue?

[ku-gew]

Well first there has to be a patch in bash itself, then you can have a patch in NAS4free.
I really hope the patch to N4F will come quickly after the bash patch.

[mekonghigh]

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Code: Select all

nas4free ~/ root~$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
nas4free ~/ root~$ 

[Martino]

I suppose that this kind of test has not be executed with root privileges...

[zambogiulio]

We did it without root privileges but the respons is the same. Who have a solution help us, please!

[kenZ71]

I saw one comment on stackoverflow that suggested a symbolic link from sh to ksh since korn shell don't support symbolic links.

I think I am going to let this be as is for another 24 hours then see what the people smarter than me have come up with. I am smart enough to know there are many way smarter than I

[MikeMac]

I have compiled patched bash at chroot, see https://translate.google.ru/translate?s ... edit-text=

(and blog4avatar did the same in jail)
But I could not transfer patched bash to host system - see comment https://translate.googleusercontent.com ... w#t1337680

[maxpower]

I don't know much of anything compared to most on this board. From what I've read though, to exploit "shellshock" through SSH, it would have to be from an authenticated user (so far as we know), correct? As a follow-up to that: if your authenticated users are given "SCP only" login for example, can they get to bash to use the vulnerability? If you're running a webserver of course it's much more dire. Apologies if these are dumb questions, I'm a n00b.

[kenZ71]

I don't know much of anything compared to most on this board. From what I've read though, to exploit "shellshock" through SSH, it would have to be from an authenticated user (so far as we know), correct? As a follow-up to that: if your authenticated users are given "SCP only" login for example, can they get to bash to use the vulnerability? If you're running a webserver of course it's much more dire. Apologies if these are dumb questions, I'm a n00b.

Actually this sounds like a great idea. Since this bug is limited to bash set all user accounts to use ksh instead.

Not a perfect fix but better than nothing.

Also, unless you get malware on your machine not much chance of infection. Of course torrents could have malware or other bad stuff.

[ava1ar]

MiceMac, thanks for sharing! I will copy my instruction here in English for those who are interested.


Part 1 - building new bash inside jail

1) Create new full jail в TheBrig. Do not forget to select
FreeBSD-amd64-9.2-RELEASE-src.txz to work with ports tree.
Start jail after creation.

2) Enter newly created jail:

jexec <jail_id> $SHELL

3) Update ports tree:

portsnap fetch
portsnap extract

4) Configure pkg:

rm /usr/local/etc/pkg.conf

mkdir -p /usr/local/etc/pkg/repos/

Create file /usr/local/etc/pkg/repos/FreeBSD.conf with content:

FreeBSD: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}

mkdir -p /usr/share/keys/pkg/trusted/

Create file /usr/share/keys/pkg/trusted/pkg.freebsd.org with content:

function: "sha256"
fingerprint: "b0170035af3acc5f3f3ae1859dc717101b4e6c1d0a794ad554928ca0cbb2f438"

5) Build new bash (may take a while, since dependencies are also being built (i.e. perl).
Use all default options when asked:

cd /usr/ports/shells/bash
make install clean

Check bash version:

/usr/local/bin/bash --version

At the monent of writing, it is 4.3.27(0)-release

6) Exit jail and shut it down


Part 2 - replace system bash with new one

1) Create a temporary folder somewhere inside the pool:

mkdir /mnt/data/tmp

2) Copy system image to this folder and unpack it:

cp /cf/mfsroot.gz /mnt/data/tmp/
cd /mnt/data/tmp/
gzip -d ./mfsroot.gz

3) Mount the unpacked image:

mdconfig -a -t vnode -f ./mfsroot -u 2
mkdir md
mount /dev/md2 ./md

4) Replace bash binary inside mounted image. Be sure to replace file inside /usr/local/bin,
since /bin folder holds just symlink to the bash, not the binary itself:

cp /mnt/data/jail/dev/usr/local/bin/bash ./md/usr/local/bin/

5) Unmount updated image and pack it:

umount ./md
mdconfig -d -u md2
gzip -9 ./mfsroot

6) Replace packed image on usb flash, remounting card as read-write:

mount -uw /cf
rm /cf/mfsroot.gz
mv ./mfsroot.gz /cf
mount -ur /cf

7) Remove temporary directory and reboot the system

rm -rf /mnt/data/tmp/
reboot

8) Check the bash version after reboot

bash --version

Should get 4.3.27(0)-release

9) Done!

Please, be sure to make a backup before doing this and check yourself you are understanding what is happening here. If you are not sure, better wait for official build, otherwise you may break your system.

[Martino]

Point is: bash is vulnerable, nothing to do.
BUT is there a chance that someone WITHOUT ACCESS to the shell or to the webgui can hack into the system?
My system is behind a router, only port 80 (for webgui with https), transmission and another one for SSH (not the traditional one) are available outside.
No webserver, no root ssh access.
Assuming that my passwords are safe, is there any real threat? I highly doubt that.

[b0ssman]

i am confused. you say port 80 is available outside.
but then go on to say no webserver. the webgui is a webserver.

[maxpower]

i am confused. you say port 80 is available outside.
but then go on to say no webserver. the webgui is a webserver.

I think I follow, but I'm completely ignorant on how the webgui works. Does it use CGI scripts? I think if the answer is no, you have nothing to worry about.

[b0ssman]

I would strongly suggest to disable the access to the web gui. If you need remote access to the web use ssh port forwarding.
Also for security I would strongly suggest disabling ssh password authentication and use public private key authentication. You would not believe the amount of brute force attacks you get on open ports.


Sent from my iPhone using Tapatalk

[fumantsu]

MiceMac, thanks for sharing! I will copy my instruction here in English for those who are interested.

.
.
.

Please, be sure to make a backup before doing this and check yourself you are understanding what is happening here. If you are not sure, better wait for official build, otherwise you may break your system.

Well I tried this way (not difficult, needs only backup and pay attention) but the updated mfsroot.gz is little bigger that the old one, enough not to be able to be copied back to /cf. Any advice?

EDIT:
for some reason with cp and not mv it worked.

[Martino]

I would strongly suggest to disable the access to the web gui. If you need remote access to the web use ssh port forwarding.

Good point, problem is that I can not establish a direct connection to that port when I'm at work (our firewall filters everything except 80 and 443 as far as I know), my only precaution is forcing https on port 80.
BUT: with only access to the webgui login screen you can exploit the bug?

Also for security I would strongly suggest disabling ssh password authentication and use public private key authentication. You would not believe the amount of brute force attacks you get on open ports.

True, anyway they have to "guess" port, username and password (a complex one) to get in, and then guess the root password; I've not seen any login attempt since I've changed the port.

[F8BOE]

Hello,

Yes Sir! You can exploit it through the "Advanced | Command line" function... If you get on the Web-GUI anyhow...

Ciao @+

[Martino]

Hello,

Yes Sir! You can exploit it through the "Advanced | Command line" function... If you get on the Web-GUI anyhow...

Ciao @+

which is NOT in the login screen. if someone manage to breake my login password, well... the shellshock is the last of my problems

[raulfg3]

Patched on latest r1004 build, please wait until was compiled and upload for download.

http://sourceforge.net/p/nas4free/code/commit_browser

http://sourceforge.net/p/nas4free/code/1004/

[F8BOE]

Hello,

Ah I see... "9.2.0.1 - Shigawire (revision 972)+1"... Good idea!

Ciao @+

[johl]

Hi all, i couldn't wait I installed FreeBSD 9.2 AMD64 in Parallels Desktop and installed the latest package through

Code: Select all

pkg install bash

the latest os-updated

Code: Select all

freebsd-update fetch install

and then move the bash-binary to my N4F with ftp on internal network and tried to start shell

Code: Select all

/usr/local/bin/bash 

and the ran

Code: Select all

bash --version

and it all worked as planned.
But first i did a backup of the old bash-binary with

Code: Select all

mv /usr/local/bin/bash /usr/local/bin/bash.old

I'll run this for awhile and hope it won't start any problems and errors due to missing libs and others.
I could posted this binary in an URL, but i don't know if you would trust that my binary is pure or if it's against forum rules. I wouldn't download any others
Best J