ShellShock!, More security holes (remote code execution through bash) - Page 1
Forum section: electronics / general

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 03:59:15 pm
content: Heartbleed meh:New kid in town is ShellShock!http://www.infoq.com/news/2014/09/bash-remote-exploitMore details:http://seclists.org/oss-sec/2014/q3/650Good old opensource.BTW Windows is unaffected. Macs are vulnerable since their bash implementation is older than dirt.Edit: Main stream caught on so expect your standard sensationalism:http://www.pcworld.com/article/2687857/bigger-than-heartbleed-shellshock-flaw-leaves-os-x-linux-more-open-to-attack.htmlhttp://gizmodo.com/why-the-shellshock-bash-bug-could-be-even-worse-than-he-1639047786http://www.zdnet.com/first-attacks-using-shellshock-bash-bug-discovered-7000034044/

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 04:09:43 pm
content: BTW the fix didn't take, so all linux based systems are still vulnerable (including Macs).http://seclists.org/oss-sec/2014/q3/690

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 04:18:30 pm
content: Oh boy, this is pretty bad (you can deploy with a simple HTTP request):http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.htmlhttp://www.troyhunt.com/2014/09/everything-you-need-to-know-about.htmlQuoteYou Linux/MacOS guys better unplug from the net and work offline for a while.Edit: Hmm I wonder if this affects Android and IOS phones as well. Thank God I got a BlackberryIf you don't need remote access to your system, you better close unneeded ports.Plus the http request will affect only those running a web-server I would assume most people don't.

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 04:34:13 pm
content: And if you think you are safe because your CGI scripts use /bin/shwell, in the majority of modern linux systems it's just a symbolic link to /bin/bashhttp://lcamtuf.blogspot.com.es/2014/09/quick-notes-about-bash-bug-its-impact.htmlQuoteQuote

author: Monkeh
author_rank: Super Contributor
timestamp: September 25, 2014, 04:53:38 pm
content: Yeah, this one's ugly.Rolled out the partial fix ages ago, seems they're still trying to confirm they've fixed it properly..

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 05:21:55 pm
content: Ok, it seems it only affects you if you can be accessed from the internet, so it will only affect servers. Unless there is a way to open a port to your net from the outside.

author: SeanB
author_rank: Super Contributor
timestamp: September 25, 2014, 05:30:35 pm
content: Busy doing an out of cycle update......... I normally have this run on Fridays.......If you have a normal home router with plug and play enabled ( as is normal default on most unless you have turned it off) then you can have a remote computer try this on the built in remote server or on the screen sharing. If you are sharing files or a directory via a FTP server you probably are vulnerable as well.

author: Bored@Work
author_rank: Super Contributor
timestamp: September 25, 2014, 05:33:37 pm
content: Quote from: miguelvp on September 25, 2014, 05:21:55 pmWhile you quoted a remote exploit example, local exploits are also possible. It affects also multi-user installations. Or when a hacker has already managed to hack into an ordinary user account. IMHO that thing is not severity 10 out of 10, but 12 out of 10.It is really, really bad. And I would guess that hack will be around for a long time, since there are many systems, e.g. cheap consumer NAS systems, media players, SOHO routers etc. with Linux, and some interface on the public Internet that are and will never be updated.

author: madires
author_rank: Super Contributor
timestamp: September 25, 2014, 05:46:46 pm
content: Quote from: miguelvp on September 25, 2014, 04:18:30 pmThe media is exaggerating. Yes, it's a nasty and bad security bug, but it's not as worse as heartbleed. In order to exploit the bug remotely via http you need to run bash based CGI scripts. No sane admin would do that. What puzzles me is that the security issue wasn't found earlier. We got bash for over 25 years.

author: PA0PBZ
author_rank: Super Contributor
timestamp: September 25, 2014, 05:58:13 pm
content: Quote from: miguelvp on September 25, 2014, 04:18:30 pmAndroid doesn't have bash, at least if you didn't root the device and put it on yourself.

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 06:09:38 pm
content: Quote from: PA0PBZ on September 25, 2014, 05:58:13 pmTrue, and then it will have busybox instead, unsure if busybox bash has the same problem.quick look on the interwebs and busybox is not affected by the exploit:http://www.pcworld.com/article/2687857/bigger-than-heartbleed-shellshock-flaw-leaves-os-x-linux-more-open-to-attack.html

author: Monkeh
author_rank: Super Contributor
timestamp: September 25, 2014, 06:10:22 pm
content: Quote from: miguelvp on September 25, 2014, 06:09:38 pm'busybox bash' is an oxymoron, there is no such thing. bash is bash. There is no other bash. busybox is not bash.

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 06:11:22 pm
content: https://twitter.com/PaulM/status/514935254478364672The #shellshock bash bug is not the end of the embedded world. Most embedded devices use busybox, which is not vulnerable.

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 06:14:41 pm
content: Quote from: Monkeh on September 25, 2014, 06:10:22 pmYou use symbolic links to busybox and it acts like the command you issue. Maybe not a full implementation of bash, but it seems it can work as bash on top of other things.Edit:http://www.busybox.net/about.htmlEdit: I guess that tweet was wrong, it doesn't map bash unless it makes it act like plain sh. In any event rooted android devices should be unaffected

author: Monkeh
author_rank: Super Contributor
timestamp: September 25, 2014, 06:16:31 pm
content: Quote from: miguelvp on September 25, 2014, 06:14:41 pmNo, it can't. busybox has an sh implementation.bash is more than an sh implementation, and a totally different codebase.

author: nctnico
author_rank: Super Contributor
timestamp: September 25, 2014, 07:07:27 pm
content: Quote from: miguelvp on September 25, 2014, 04:18:30 pmMuch to do about nothing. Webservers typically run as a sandboxed user so most that can happen is deleting a website IF the user the webserver runs with has write access to the directories with content (probably not). Desktop Linux systems sit nicely behind a firewall without access from internet.Many years ago I did a scan to discover Windows networking shares accessible through the internet. I managed to get into many home and business servers. You'd be amazed how many company Windows file servers are also used to host the company's website

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 07:26:08 pm
content: It could be deleting the server or sending each transaction of unencrypted data to someone.or the cache files or full mongodbs or whatever.Use it to fetch custom code from the net that you prepared to exploit the server further, then use it again to launch it, or really you can do both in one shot.yeah, no worries.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: September 25, 2014, 07:33:39 pm
content: Isn't the "proper behavior" still a major vulnerability? You can still pass in function declarations via environment variables through CGI. Since function declarations take precedence over binaries in the PATH, it means you can effectively "replace" standard command line utilities with your own custom code.eg:$ env ls='() { echo this is a fake ls; }' bash -c "ls"this is a fake lsor$ ls$ env echo='() { touch file; }' bash -c "echo 5"$ lsfileAn attacker could replace ls, cd, read, echo...any number of things. Then if any of them are called in the script, the attacker's code gets executed.Good thing I don't use CGI...

author: Monkeh
author_rank: Super Contributor
timestamp: September 25, 2014, 07:39:06 pm
content: That's why you make explicit calls to an executable.

author: gxti
author_rank: Frequent Contributor
timestamp: September 25, 2014, 07:49:58 pm
content: Quote from: suicidaleggroll on September 25, 2014, 07:33:39 pmEnvironment variables set by CGI are prefixed, e.g. Cookie -> HTTP_COOKIE. So when you don't have crippling bugs in the shell that let you turn EVERY environment variable into an arbitrary code execution, it's not practical to replace system binaries. But securing shell CGIs (and CGI in general) is still hard and probably best avoided.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: September 25, 2014, 07:55:26 pm
content: Quote from: gxti on September 25, 2014, 07:49:58 pmI'm glad to hear that, thanks.

author: mrflibble
author_rank: Super Contributor
timestamp: September 25, 2014, 08:33:26 pm
content: Ohnoez, not another security issue without even the remotest chance of impact.Layered security is such a wonderful thing. Assume that everything is shit, and act accordingly. Then when one particular item in the chain actually turns out to be shit, you still don't have to PANIIIIIIC, but you can fix things at your leisure. Move along, nothing to see here. Besides, cgi bin scripts? What now? Did we revert to the past millenium and I didn't get the memo?Local access as Bored@Work points out would be a valid concern. Assuming you didn't put every single mofo with shell in a statically linked restricted jail. Have fun with that.As far as I'm concerned heartbleed was nastier.

author: Marco
author_rank: Super Contributor
timestamp: September 25, 2014, 09:06:24 pm
content: Quote from: nctnico on September 25, 2014, 07:07:27 pmThese are webservers which can execute bash ... I think it's safe to say they will often be able to execute a lot more (and thus have plenty of local exploits to work with for the attacker).

author: miguelvp
author_rank: Super Contributor
timestamp: September 25, 2014, 10:13:19 pm
content: For example, this device is vulnerable.Edit: well the supporting software for this device.http://www.linear.com/products/smartmesh_wirelesshartNah, don't panic everything is quite alright!

author: rob77
author_rank: Super Contributor
timestamp: September 25, 2014, 11:06:12 pm
content: i think guys you should definitely disable your panic modethe whole thing is not so severe.... i didn't even bother to check my servers... why ?1. the title itself "remote code execution through bash" is a sheer non-sense... how the hell anyone could remotely execute something via bash ? that bash has to be exposed through some other means (http server with CGI, some kind of remote login...etc...), no way to remotely execute anything via bash alone.2. who the hell is using CGI written in shell scripts nowadays ? not me...3. local users ? once the user is logged in , the user can execute anything under his shell - if he prefer to craft a creepy environment variable containing his command and calling a sub-shell to execute it instead of writing the command directly...... well... if he likes it that way - i don't give a shitthis bug is NOT elevating any privileges.i'm not saying the bug is welcome... not at all , it's ugly... but let's be realistic... the impact is far less serious as described in the media.

author: sleemanj
author_rank: Super Contributor
timestamp: September 25, 2014, 11:22:36 pm
content: The first thing to know, is this is a bad bug. Really nasty. Nastier than heart bleed.The second thing to know,it is NOT a privilege escalation bug(in itself, but once you can run something on a server you have a vector to perform some other attacks against other things to escalate perhaps... keep your systems patched guys),you can't use this (on it's own) to get root. Of course, if your mental enough to run your web server as root that's a different matter, mentals shouldn't be server admins."CGI" is affected, but do not be fooled "I don't use bash CGI therefore safe" - if your, for example PHP, or perl or .... calls out with system() type commands which use a shell and the shell is bash, those dodgy env variables could get pushed through and executed. Once the variables have been injected to the web server, then anywhere in that process that bash could fire up is potentially a problem, it doesn't necessarily need to be a bash script CGI. If somebody looks and finds such a vector in say, wordpress, boy, that'd make for a fun time.SSH is affected but this is really only of interest when your SSH session is normally command-restricted (that is, you have one command that it runs, or some set thereof), again, it's not giving somebody access to a server they didn't have access to already (I think) but it could give them the ability to run some command that they wouldn't normally be able to (but still have unix permissions which allow them to outside of SSH, so can't be that much of a problem).

author: Marco
author_rank: Super Contributor
timestamp: September 26, 2014, 12:01:44 am
content: Quote from: rob77 on September 25, 2014, 11:06:12 pmIt doesn't need too, there's never any shortage of them.

author: amyk
author_rank: Super Contributor
timestamp: September 26, 2014, 10:08:19 am
content: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/Now you should start worrying...DHCP viabash scripts? WhoTF thought that was a sane idea?

author: madires
author_rank: Super Contributor
timestamp: September 26, 2014, 10:27:25 am
content: Quote from: amyk on September 26, 2014, 10:08:19 amSimply change your default shell (/bin/sh) and check the dhcp hook scripts. AFAIK most linux distributions don't use bash as default shell anyway.

author: rob77
author_rank: Super Contributor
timestamp: September 26, 2014, 10:53:47 am
content: Quote from: madires on September 26, 2014, 10:27:25 ammany distributions have the /bin/sh privided by a symlink to bash...but anyways.... how many of you guys are using linux as a primary os on your laptops and connecting to UNKNOWN networks with it ? how many of you are running CGI scripts written in shell ?everyone is screaming and spreading FUD, while the severity of the issue is almost none for most of the linux installations.if you are afraid, then either install a patch (most of the vendors released the patches) or install a different shell and deinstall bash.

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2014, 11:02:38 am
content: Quote from: rob77 on September 26, 2014, 10:53:47 amWhere do I get the patch for my wireless router, smart TV, printer etc etc?Yes, I know these are behind my firewall and GRC reports limited external access, but all they need is one way into my network...

author: Monkeh
author_rank: Super Contributor
timestamp: September 26, 2014, 11:31:58 am
content: Quote from: tggzzz on September 26, 2014, 11:02:38 amWhat makes you think you need a patch?

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2014, 11:59:54 am
content: Quote from: Monkeh on September 26, 2014, 11:31:58 amThey all contain old unpatched versions of linux including webservers. That's sufficient for concern, and you don't have sufficient knowledge to allay that concern; nobody does.Welcome to one of the key emerging problems with the "Internet of Things".

author: Monkeh
author_rank: Super Contributor
timestamp: September 26, 2014, 12:01:53 pm
content: Quote from: tggzzz on September 26, 2014, 11:59:54 amSure, but as far as this issue goes.. they most likely don't have bash. Very, very few embedded devices do, bash is huge.Quote.. I have enough knowledge of embedded software not to be concerned about any of mine.

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2014, 12:12:35 pm
content: Quote from: Monkeh on September 26, 2014, 12:01:53 pmSure, there's neither need nor reason for bash to be in embedded systems, but that's not much assurance given the marketing imperative to get products out-the-door "yesterday".Having witnessed the amount of cruft that has accumulated in networked printers' firmware over time, and having seen the ineptitude of some smart TV manufacturers, I'm not so sanguine.

author: rob77
author_rank: Super Contributor
timestamp: September 26, 2014, 12:15:09 pm
content: Quote from: Monkeh on September 26, 2014, 12:01:53 pmsame hereactually anyone with deep knowledge knows it's not worth of even checking the systems

author: Monkeh
author_rank: Super Contributor
timestamp: September 26, 2014, 12:17:46 pm
content: Quote from: tggzzz on September 26, 2014, 12:12:35 pmThe bulk of them use off-the-shelf embedded distros as a base, these almost exclusively do not include bash.I agree there's a problem emerging, though. A sane, minimal, and automatically updateable base distro needs to be produced for embedded and 'smart' devices so the manufacturers can focus on their own problems. Unfortunately, this will prove exceedingly hard to get traction with, primarily thanks to embedded hardware manufacturers who refuse to write proper drivers, let alone comply with licensing requirements. There's effectively no useful modem (cable, DSL, or otherwise) running Linux with an open driver in the wild, for example.If anyone does know of a VDSL2 chipset with an open driver, please, let me know, I have an Isreali turd hanging on my wall I could do without.

author: rob77
author_rank: Super Contributor
timestamp: September 26, 2014, 12:18:53 pm
content: Quote from: tggzzz on September 26, 2014, 12:12:35 pmthat bash have to be oxposed to the internet in order to be a threathow many of you guys have public IP address on your TV, printer whatever ? is your TV even have bash in the firmware ? if yes... it is exposed in any means (cgi, telnet... whatever) ?so think guys before you state your TVs and printers are in danger

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2014, 12:51:18 pm
content: Quote from: rob77 on September 26, 2014, 12:18:53 pmNot true. If there is a compromised machine on your internal network then you are exposed. Or do you think that all machines in a botnet are directly attached to the internet with no firewall?QuoteNobody has stated that. Are you?Don't presume you have thought of all threats (let alone understood them); a decent threat analysis is non-trivial.