Student's Linux daemon 0-day triggers InfoSec Institute outcry Controversy has accompanied the discovery by a student of a critical vulnerability in BackTrack, a flavour of Linux that's a favourite among security pros. The previously undiscovered (hence zero-day) privilege escalation bug in the network penetration-testing distro was discovered during an ethical hacking class organised by …
In fact, it can be installed to the main hard drive, like other popular Linux distros. Moreover, it can be installed directly on a USB stick. So this way, you get the best of both worlds. You get a persistent installation (i.e. where the changes made are persistent, updated on the USB as if it was a regular hard drive), and you do not mess with your existing hard-drive OS installation.
Personally, I think that except for quick and dirty tests, most "serious" users will perform a persistent installation.
And *IF* you have physical access. For those people who might be running wicd on a server with multiple non-root users then this is a significant issues, the fact that it was found when using BackTrack is irrelevant, misleading and poor journalism. The vulnerability exists within the widely used wicd daemon itself and therefore affects Linux in general not just BackTrack!
I know in the 24 hour news cycle fact-checking and editing are pretty much dead, but come on guys, do your homework.
http://www.backtrack-linux.org/forums/showthread.php?t=49411
Response from Muts @ Backtrack:
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.
Another response can be found in our blog - http://www.backtrack-linux.org/backtrack/backtrack-0day-privilege-escalation/
Hmm, yes, all good points very well made. A saving grace is that the article explains that it's a wicd bug that affects other distros - but will definitely keep this in mind next time.
And I'm speaking as a Debian+Ubuntu user who left his packaging and distro hat in the glovebox.
What bugs me is that this ethical hacking class didn't seem to get as far as responsible disclosure (see the Debian thread). Fair comment?
@diodesign: (is that you John??) Yes, from your article it does become clear to anyone vaguely familiar with Linux security and bug tracking that the problem was (it's been patched already M$ trolls!) with wicd rather than BackTrack. That was my immediate thought (having recently played with wicd after failing to get f***ing Network Manager to play nicely on a Fedora laptop recently).
The problem is that your headline: Student stiffs penetration tool BackTrack Linux with 0-day screams "Ooh! Clever InfoSec Linux White Hats Caught With Pants Down!" - and with your pedigree in reporting security stories recently we know you can do much better. We all drop the ball now and again :-)
But still, BackTrack has one single root user anyway.
Time to make a distro that doesn't have a root user. Can't break a PC you can't configure. :-)
Note the update on the Infosec website...
Update 4/12/12: The wicd team has released a new version that fixes this bug (CVE-2012-2095). The title of this advisory upon release has been, and always has been "wicd Privilege Escalation 0Day
Tested against Backtrack 5, 5 R2, Arch distributions". When we tweeted and emailed to mailing lists the notifications of this vulnerability, we incorrectly shortened the title and called it "Backtrack 5 R2 priv escalation 0day ", which is misleading and could lead people to believe the bug was actually in Backtrack. The bug has always resided in wicd and not in any Backtrack team written code. We apologize for the confusion to the Backtrack team and any other persons affected by this error. We feel the Backtrack distro is a great piece of software and wish muts and the rest of the team the best.
Patching on linux may well be quick, but migration from unstable into the stable is not always quick. There can be several days, weeks or even months before the initial unstable, untested patch gets into the stable repos.
If you're running a production system you don't ever install unstable patches, indeed Red Hat et al will cease your support if you do. I don't know how long it's taken in this case to get to stable repos, if indeed it has, but I do know that I've waited over a month for updates to fedora and centos before now.
As wicd is distributed as part of the BackTrack distribution (the clue is in the second word there), there is something wrong with BackTrack. The fact there is also something wrong with many other GNU/Linux distributions does not change this fact (though does change the story somewhat).
On another note, the "It's not our fault, go whine to someone else!" response given by BackTrack does demonstrate why proprietary operating systems dominate the market. Simply put, it's nice to know where the buck stops.
it depends. If you have decided to include a software product that needs escalated privilege (root or admin), then that is not Microsoft, and you must take some responsibility yourself, and should also blame the vendor of that package.
If it is software that does not require escalated privilege, and can get it using the package, then that would of course implicate Microsoft as well.
But in your example, it would be better to ask if Microsoft should take any responsibility for something they include from a third party as part of a windows installation (such as the CD and DVD burning code licensed from Roxio), as this is more like what Linux Distributions do.
Microsoft does not include third party apps in Windows, that would be the resellers: Dell, HP, Lenovo, Samsung, Sony, etc. So again, no liability to MS for Roxio software.
Where MS gets into trouble is that they do include certain certain functionality in their "kernel" that more properly belongs on a different functionality level, like Internet Explorer.* They exacerbate the issue by including things like activeX to make programming easier, but that adversely impacts security.
*With more recent OSes MS have tried to make this differentiation in their reporting, but since it still all comes in one mostly un-editable package, I find it a less useful distinction than it is in Linux.
"Read the EULA - they're not responsible for anything at all anywhere ever"
They wish. Just because you write something in an EULA doesn't mean you can enforce it - especially if it flies in the face of consumer protection law. (As Apple have recently discovered in Italy).
If Microsoft ship a tool with a security vulnerability with their OS, then I think they should be held responsible, yes.
Similarly, if BackTrack (and Debian of course) ship a tool with a security vulnerability with their OS, they should be held responsible for it.
I'm also tempted to say that if an OS vendor supplies a repository of packages for download (i.e. they're endorsing them), they should also be responsible for any security vulnerabilities in that, similarly to how Apple/Google are blamed for allowing security vulnerabilities in the AppStore/Play. I imagine that not many people will agree.
A user installing a 3rd party application from some unofficial source should obviously not be a reason to blame the OS vendor.
The issue is that there are a lot of people represent that everything that is available in distributions is "linux", however when one of these packages goes wrong, they say something along the lines of "it's for the package's developers to sort out" and "nothing to do with the OS." This doesn't happen for MS, MS make the stuff you download from them or the stuff on the install CD, there is a clearer demarcation point.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
