Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Linux

Critical Flaw Found In Backtrack Linux 84

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."
This discussion has been archived. No new comments can be posted.

Critical Flaw Found In Backtrack Linux

Comments Filter:
  • Yo Dawg! (Score:5, Funny)

    by ColdWetDog ( 752185 ) on Wednesday April 11, 2012 @06:59PM (#39651665) Homepage

    I heard you like pen testing so I put a pen test on your pen test!

  • That's what I clearly heard the admin of the threatpost's web server just exclaim.

  • From what I heard (Score:5, Insightful)

    by antonymous ( 828776 ) on Wednesday April 11, 2012 @07:08PM (#39651765)
    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...
    • Re:From what I heard (Score:4, Interesting)

      by Taco Cowboy ( 5327 ) on Wednesday April 11, 2012 @07:26PM (#39651977) Journal

      Many other distros also carry wicd

      Are other distros also affected?

    • by 228e2 ( 934443 )
      True.

      And as a pen tester, I've yet to use this on an online network. 100% non-issue for me.
      • by Architect_sasyr ( 938685 ) on Thursday April 12, 2012 @05:00AM (#39655397)
        Any good pentester maintains good physical security (because, you know, you carry your laptop with you at all times), firewalls their own machine, and maintains a fairly decent log of what is crossing their interfaces anyway.

        Unfortunately most of the people (I'd go as far as 95-99%) on the backtrack forums are neither pentesters nor good. They use wicd because they don't know how to edit a config file or run their own wpa_supplicant. Most of them go as far as trying to use BT for their regular day-to-day stuff. Idiots. But the backtrack team put up with them, so something like this becomes massive news.

        I didn't see headlines when the wget vulnerability was in Backtrack 3...
  • by davidshewitt ( 1552163 ) on Wednesday April 11, 2012 @07:10PM (#39651789)
    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).
  • it appears (Score:3, Informative)

    by koan ( 80826 ) on Wednesday April 11, 2012 @07:27PM (#39651981)

    Backtrack repository has the fix already.

  • by account_deleted ( 4530225 ) on Wednesday April 11, 2012 @07:49PM (#39652219)
    Comment removed based on user account deletion
    • by Shoten ( 260439 )

      Actually, a lot of people install Backtrack and run it as the resident install on their hard drives. Not what I would do, but then, not everyone is able to build their own system for pen-testing in the first place.

      • Eh, you can't make scissors that are completely safe for folk that insist on running with them.
    • by Anonymous Coward

      "running entirely from a ramdisk in memory"

      As opposed to a ramdisk running not in ram?

      ; )

      (I know, I know... Bla bla bla ramdisk is a misnomer etc. Your sentence still reads funnily ; )

  • Why oh why do people still make and use systems/apps/tools/interfaces/etc that use in-band signaling and thus require that their inputs be "sanitized"? Can't everyone see that sanitizing inputs is a fool's errand? You'll ALWAYS miss something, or the next version will have a feature you forgot to screen for, or something. In-band signaling is BAD BAD BAD and any system that uses it is doomed to an endless series of X-injection attacks.

    For example (and yes, I realize this has nothing to do with SQL, it's
    • 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 programmer

      • 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.

        I don't so much care how "thick" your data access layer is - a thousand layers of code or just a rule - the important thing is that at the bottom you MUST use bound parameters instead of doubling all your quotes and wrapping it in quotes.

        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.

        Poor choice of words, perhaps - what it really boils down to is, don't let your users write your source code. Seems pretty obvious when you say it that way, but so many things like SQL injection attacks, XSS browser problems, etc, all come down to taking a string of user in

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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 [owasp.org].

      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.

  • by seifried ( 12921 ) on Wednesday April 11, 2012 @08:20PM (#39652517) Homepage
    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.
  • This is a complete (Score:5, Informative)

    by jakeguffey ( 587607 ) on Wednesday April 11, 2012 @08:45PM (#39652747)
    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.
  • by Anonymous Coward on Wednesday April 11, 2012 @09:03PM (#39652921)

    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.

  • I use a CD to boot BackTrack. It's always safest if you do this on a machine with a disable hard drive.

    If you're an infosec pro, it pays to use belt and suspenders.
  • 1. Advertise 0day on Linux distro
    2. Publish unofficial "fix" with trojan payload
    3. Pwn all the computers of the world's most paranoid hackers
    4. ?
    5. Profit!!!!

  • Seems to me Infosec are trying to mis-represent this bug in order to get traffic to their website. Calling it it a "Backtrack 0day" is a blatant attempt to make this into more than it is for the sake of self glorification. People who actually understand security see right past this, which sheds a bad light on the Infosec Institute.

  • ' An unofficial patch is available from InfoSec Institute. Koziol said that an official patch is being tested now and is expected shortly." Linux will always be more secure than macs.

Some people manage by the book, even though they don't know who wrote the book or even what book.

Working...