Slashdot Mirror
Critical Flaw Found In Backtrack Linux
chicksdaddy writes "Threatpost is reporting on a critical security flaw in the latest version of Backtrack Linux, a popular distribution that is used by security professionals for penetration testing. The previously undiscovered privilege escalation hole was discovered by a student taking part in an InfoSec Institute Ethical Hacking class, according to the post on the group's Web site. 'The student in our ethical hacking class that found the 0day was using backtrack and decided to fuzz the program, as well as look through the source code,' wrote Jack Koziol, the Security Program Manager at the InfoSec Institute. 'He found that he could overwrite config settings and gain a root shell.' An unofficial patch is available from InfoSec Institute. Koziol said that an official patch is being tested now and is expected shortly."
I heard you like pen testing so I put a pen test on your pen test!
Faster! Faster! Faster would be better!
The program in question is wicd, which is a wireless network manager. And it's not like BT is a particularly secure distro - it's for pentesting, so most of it's functionality is only useful if you run as root...
A fair number of the tools on backtrack have to be run as root. If you use the LiveCD or boot it from a flash drive (which is what I usually do), it instructs you to log in as root (with the default password of toor). Unless you were running Backtrack on a server with unpriviledged users, I don't see what the issue is. Just don't open any ports and you'll be fine (and if you're pentesting, why would you - you don't want to be detected).
Backtrack repository has the fix already.
"If any question why we died, Tell them because our fathers lied."
Yeah, I can't believe people fall for th
Oh look. It is a picture of two kittens who are playfully romping in the grass. This picture is really cute.
What? No, it's
So cute!
Random Thoughts From A Diseased Mind (Not For Dummies)
Oh noes, someone has pwned my LiveCD linux distribution, running entirely from a ramdisk in memory! Whatevers shall I do?!
*reboots*
You need to be able to send arbitrary Dbus messages, so you need either local access or to remotely compromise the system (in which case you already won). This article is ridiculous and much ado about nothing.
non-issue. According to the advisory, this particular issue "Spawns a root shell [and h]as not been tested for potential remote exploitation vectors." As has been stated multiple times earlier already, BT is generally used as root locally and (until someone determines remote exploitability) this is a local-only exploit. TFS is wrong. This is not a "critical flaw in BT," but a flaw in WICD that allows privilege escalation. Still something that definitely needs fixed, but if someone has local access to your box, you can pretty much assume they already have root.
From the official response (http://www.backtrack-linux.org/forums/showthread.php?t=49411):
This post is a bad example of a bug report, for several reasons.
1) The title of this vulnerability should probably be "WICD Priv Escalation". As such, it should probably be reported to the WICD developers, as opposed to the BackTrack development team. If you still felt the bug report should be posted to us, the right place to post it would be "BackTrack bugs" (although it is not), or even better, our redmine ticket system.
2) Giving the pre-requisites for the exploit to function would be helpful. In this case, you would need to create a non root user in BackTrack, have a remote attacker access BT with that non privileged account or have an unprivileged shell from a previous attack against another service, and then have that user attempt to connect to a wireless access point (assuming wicd is running as root). This is far from the default configuration in BackTrack, which further negates the title of this vulnerability.
3) Making a mountain out of a molehill for the purpose of promoting a product or service is generally frowned upon by the security industry, especially when one already has a bad reputation.
4) Once this bug is tended to by the WICD developers, we will use their official patch rather than patching our packages using untrusted sources.
Oblivious indeed. All input gets sanitized, even if it's a simple sanity check, for example percentages should be between 1 and 100 (if >100 doesn't make sense). Numeric data should be checked to be sure it's numeric. Null integers and strings should be converted to a NULL database value, instead of an implicit ToString() conversion giving an empty string, depending on the language. Using a pass-through library to connect to the database, allowing nothing to escape unchecked, is what smart programmers do. Some sort of data access layer.
Bobby Tables illustrated one of the most common attack vectors. Not using bound parameters is very common so much so that I have yet to see an introductory text on ASP or ASP.NET that explicitly and routinely uses bound parameters. Most issue a disclaimer that error checking has been omitted for clarity. So you have people who should know better, but don't. Instead, you use a data access layer, that always binds parameters.
Kinda like I said above. Only you claim that you will miss sanitizing something. So what if you forget to use bound parameters? Oh that's right, things work perfectly in your view of the world but everyone else is wrong. Use a data access layer, access everything the same way. And while you're at it, you might as well sanitize the data as well, right? After all, if it looks like an injection attempt, shouldn't you at least log an IP, or user ID, or something? A responsible dev would.
In-band signaling... I'll leave that for others if they want to rip it apart. I assume you mean escape sequences, replacing control characters with escapes specifically. There are common ways of replacing, and common ways to defeat common ways of replacing. It has nothing to do with in or out of band signaling.
If you are talking about creating a protocol, such as TDS or SMB, or TCP, or anything else, it's very easy to add error-checking to ensure OOB data is treated as expected, and in-band signaling is considered an error condition. If you are talking about checking for escape sequences in a protocol and passing that directly, unchecked, you're talking about little Bobby Tables.
"In-band signaling" is, in the case of SQL, a SQL injection attack waiting to happen, and exactly the condition XKCD was describing. Using bound parameters relies on the underlying library to generate the correct OOB escape signals to describe the packet and detect anomalies. IF you have a bug in the binding, such as the case here, it doesn't matter if it's in or out of band. There is a bug, and it will likely be discovered sooner or later.
So I assume you are also saying: Always assume that the lower layer library has a bug, and sanitize your inputs just in case, so your application is not hacked by an underlying bug. That is what you are saying, right?
Ummm.. fuck parent straight up the ass for that idiocy.
Validating your inputs is just one of many important parts of a complete security solution.
There is a good reason you'll find "Input Validation" given its own section starting on Page 5 of the OWASP Secure Coding Practices Quick Reference Guide.
But don't be too hard on CapOblivious2010 ... developers like that are the reason you'll still find plenty of work writing security code for decades to come.