So are we seriously going to have 14 year old script kiddies calling tech support?

"Uh, yeah, like, dude my kit here ain't runnin' right, gets me all the way to the admin password but then it like stops. Okay, I'll hold."

It's all very well security researchers crafting malicious tools for their own benefit, but when they're packaged to be script-kiddie friendly does the damage not outweigh the benefit?

Immunity Inc. are based in Florida. As such, they are accountable under US law. If the yanks can extradite a UK resident (Gary McKinnon) for cracking, surely they are also capable of bringing someone to account who makes a rootkit toolkit to facilitate this crime? Or is being accessory to cybercrime not yet a felony?

I shall be interested to learn exactly what "burrowing deep inside a server's processor and availing itself of debugging mechanisms available in Intel's chip architecture" means. There have been several disclosures recently about exploits in CPUs' firmware. Obviously, a mere operating system is going to have trouble working around defects in the CPU's design and microcode. The vendors themselves need to release new microcode to resolve this. This vector of attack must be equally applicable to Windows, despite the whole GNUey nature of this disclosure.

Regardless, I shall be sleeping soundly tonight in the knowledge that my address space + stack randomised, hardened with mudflaps Gentoo servers will not be compomised by any attack aimed at less dynamic operating systems. Source-based distros FTW!

PS You're welcome to visit the UK's only realtime art demoscene exhibition: September 12th-14th, Sidmouth, Devon. http://www.sundowndemoparty.org/

Look out, GNUtards, your "safe and secure" Free (as in Freedom) OS is vulnerable to a Free (as in GPL v2) DIY rootkit! Now no one is safe from hackers! No one! hahahahahahahahahahah...

Now, I could take the sane and conservative path, and explain that adding a rootkit to a Linux PC would require administrator [root] access to the system, and that preventing such installations would be as easy as disallowing admin access by default. But that would be so Windows 2000/XP/Vista of me. After all, this is supposed to be an open (oops, wrong word, sorry RMS), um, Free (as in Freedom) system not subject to the same constraints as a proprietary system.

Do you run Linux as root, too? Welcome to the rest of the world.

Join the botnet. I am a timeless chorus, join your voice with mine and sing peace everlasting... or something Gravemind-ish like that.

There is loads of stuff on unix rootkits, the open ones are obvioulsy the prime candidates, but at least one can check, which is something proprietary finds harder to achieve. And hey, people write them when learning how the kernel works, most don't hit the wild, but there is a load out there.

Personally I think Linux is now popular enough to warrant people targeting it.

The user base is very amusing as well, a lot of the windows refugees just have a really lousy security attitude, and they are starting to bring it over to Linux. They want convenience, and of course convenience means security holes.

Windows is still simpler to crack, I would imagine, and the user base whilst decreasing has now a much higher % concentration of, well how to put it, security challenged users. But, the Linux % of possible candidates has increased as well.

The attacks will tend to be distro specific though, each distro does things differently, and each has a different set of people. Sure there are exploits across the board with Linux, but the kernel is a pain to target that is what is done differently in most distros (ironic eh :) ).

And if you keep up to date, the window of opportunity is kept small, (it is not a silver bullet - but it is close to one). So still those who don't update and use Linux are again the window refugees, bastd's see that is why we don't really want them :)

And the super distros aren't great, the best distros are the ones which have enough developers to keep up with the releases. Attracting any old Thomas, Richard, or Harry to your distro doesn't really help. Ubuntu is the one that wil probably be targeted first, they have a huge user base.

And hey, I have seen what Ubuntu systems are like, I went through a phase of putting a couple in to test for folks, but they are coming off now, things break too easily, and whilst the fix is okish, the idea was to reduce admin time, and it just doesn't.

The techier distros, whilst the setup is longer, the admin is very simple.

But yes it is coming, Linux has more security potential but I think people will be paying for it just as they do on Windows, but it will be more effective. And there will be less charlatans hopefully, than in the Windows world, most security stuff is quite low level, you tend to have to know what you are doing.

And we should start to see a rise of the more hardened systems, but again I think that will be the retreat of the old guard, your average user, will find that too hard to work with, if they even know of their existence.

"burrowing deep inside a server's processor and availing itself of debugging mechanisms available in Intel's chip architecture."

So is this chip specific, or generic enough that the AMD crowd shouldn't feel too smug?

Enquiring minds want to know...

Wouldnt be surprised if there was a company in Redmond Wa is spreading around money for research into "Linux security". And thats the beauty of open source licensing is that you can make a closed source OS that is100% compatible with Linux without worry of lawsuits as no one can hold ownership over someone else on code based on open licensing. And I predict that after a while such closed source Linux compatible OS's will start sprouting up and attracting customers. I actually hope hackers do start targeting *nix OS's because *nix was built buy true hackers who will have a field day making their OS's a moving target way out of range of a philipine hackers "I love you" virus.

It would actually surprise me if some of the more notorious viral strains weren’t either accidentally or even intentionally released by the folks that write the AV stuff. I remember a few years back when something ‘slipped’ out of McAffee and all hell broke loose for a week or so and then it got quiet.

As for Redmond, they’re just lazy. When there’s actual money at stake, you’d be surprised how fast MS can generate something to ‘just get by’ until the next disaster comes along. Because, that potentially impacts future revenue and reliance on their products, which has a direct relation on their stock.

Wow I want a keyboard like yours that will type "ONE" out for me when I am typing !!!!!1111 :) Sorry that one had me on the floor.

On a side note this so called "rootkit" does it actually login as ROOT to take control of your KIT??

/Ok yes yes I know mines the one with Bad Puns'R'Us on the back

by the time you've been rooted, your kit has normally gone anyway...

"Regardless, I shall be sleeping soundly tonight in the knowledge that my address space + stack randomised, hardened with mudflaps Gentoo servers will not be compomised by any attack aimed at less dynamic operating systems. Source-based distros FTW!"

Better get yer Mum to fit a lock to the basement window first ;)

Oh, wait, all my machines are AMD. Ho-hum.

"Do you run Linux as root, too? Welcome to the rest of the world."

...um, Nope, i only use the root account when absolutely necessary, fairly standard when using linux really to have more than 1 user account to limit rights, security by design you see you, quite clever really.

Are you on the security mailing list for your linux distro? Exploits to allow standard users to run as root are not as uncommon as you'd think

No it did not. It never will. Skiddies abilities might get nastier as time goes on, but if they don't have a handily prepackaged attack that still works, they're screwed, and have to wait for the next release.

> "Regardless, I shall be sleeping soundly tonight in the knowledge that my address space + stack randomised, hardened with mudflaps Gentoo servers will not be compomised by any attack aimed at less dynamic operating systems. Source-based distros FTW!"

Coming from an OpenBSD point of view, I wouldn't agree at all that being source-based is a security benefit at all. Cunning tricks at the compiler level help catch coding mistakes, but it needs a thorough code audit to actually find all the flaws, some of which will be serious enough that no amount of voodoo will stop you getting rooted.

Ultimately, all desktop OSes have the same weakness... given an idiot with root level access, no security scheme in the world is going to help you.

Is this new? I mean, VmWare does a pretty good job of hiding itself from the client OS. It's not perfect, but it isn't trying to be. It's just trying to be sufficiently invisible to avoid fouling stuff up. The fact that someone can do a better job of hiding is hardly surprising if you've read the Intel manuals. Both Intel and AMD are actively trying to make the perfectly invisible host OS a possibility, so it is hardly surprising if they've succeeded.

No, this is not new. It is, however, missing the crucial ingredient of "how I get this rootkit onto your system".

Yuo must bee new heer!

"burrowing deep inside a server's processor and availing itself of debugging mechanisms available in Intel's chip architecture."

So is this chip specific, or generic enough that the AMD crowd shouldn't feel too smug?

Enquiring minds want to know..." .... By James Posted Friday 5th September 2008 02:07 GMT

James,

It is a Generic Failing in Intel Architecture allowing for Systemic Catastrophic Cracking ........ of Key Codes and their Rendered Systems.

But you can be assured that Script Kiddies are the least of your worries for they would have neither the Inkling nor the Necessary PreRequisite XXXXPerience to use ITs Embedded Cloaked [as in Covert/Stealth] Facility to Proxy Third Party Beta Advantage.

It is probably definitely the worst Nightmare Scenario for Any and All Systems trying to hide away their dirty laundry and remain Scot Free and untarnished by their decidedly perverse and crooked actions. For that, it is a most welcome Development from the Land of the Once Free ...... and now all Sold Out and Squandered to Private Lobby Interests/Spivs in Zoot Suits aka Shysters and the Very Lowest of the Low.

It will be a Most Interesting Time to See and Read of what they will now do, with their Systems Cracked Wide Open to their Sources ..... Spotlighting/Harry Limelighting the Architects of Global Woe.

Can we please acknowledge that suffixing a word with -tard is barely worth even referring to as an insult? In fact I would argue it is a gang tag for Orlowski fanboys.

The advantage of linux' method of disabling admin access is that you can log in a single program as root while continuing to work as notroot. I sometimes wish Mickeysoft would wake up and enable this in Windows.

I'm not saying it can't happen. It is possible to engineer root access to a Linux or UNIX system that is managed remotely as long as there is a single vulnerabillity, even a non-root one. BUT, using root as infrequently as possible rather than having admin rights all the time (typical Widows user) must be more secure, even if it is only by degree.

All the time you have the concept of escalated privileged to perform some function, you have the posibillity of this being abused. This will NEVER completely go away, regardless of the OS, until computers are so locked down that you cannot change anything. So, make it so that you use the escalated privilege as little as possible. No version of Windows I have come across has taken this line, with the result that too many people HAVE to run as admin for their apps to even work correctly.

So even though this development is worrying, I am still slightly smug, but cautiously so, and with some respect for the skill of the people writing the rootkits. They are MUCH cleverer than most of us who mearly comment on the effects of their work. Pity about the script kiddies, however. But you cannot control information the way you can a physical object. Once it's out in the wild, its out, whether by design (Open Source) or by accident (leak). The vector makes no real difference.

Strange, the sysadmins in the company where I work use a Windows option called 'RunAs..'. They don't seen to have any problem running a program in Admin-mode while I am logged in with my normal user. By the way, I just checked in my old Win2000 box, and that has the option as well.

Maybe you should have checked before?

if you have root access you have root access thingy.

Hard to find???

How about three lines of code to compare MD5 of the kernel and associated files every now and then?

"The advantage of linux' method of disabling admin access is that you can log in a single program as root while continuing to work as notroot. I sometimes wish Mickeysoft would wake up and enable this in Windows."

You've never heard of "runas" then? Been an integral part of windows for gawd knows how long.

Once a system (Linux, Windows, whatever) has been penetrated and left with a sufficiently sophisticated rootkit, there is no guaranteed way for it to be able to detect the damage done by itself. Theoretically it's possible for no way to exist. The only answer is a periodic offline scan, i.e. shut the system down and scan by booting off some other trusted medium, such as a CD. Once the files on the disk are inspected by a non-compromised kernel, discovery of permanently-installed rootkits should be easy.

Easy to do with Linux, that is. With Windows, Microsoft goes out of its way to prevent you from running it off a CD, and the antivirus companies don't seem keen to send one down this road either. (I guess it would be embarassing to be seen using Linux to clean up messed-up Windows boxen).

Of course if your system has a security hole, there's nothing to stop a hacker breaking in again after you reboot, until that hole is discovered and patched. A daily 4am reboot might at least raise the risk and effort level for hackers, if being up 23.95x7 will do.

For CPU manufacturers - perhaps the hardware support for kernel debuggers should come with a disable instruction, such that once disabled, only a hard reset will re-enable?

@AC 0113 - You are actually blaming security problems in Linux on Windows users? Brilliant.

@Drak - Are you seriously suggesting that MS fund research into producing root kits for linux? That seems to be the case from your comment.

@AC 0310 - Yes, McAffee write viruses, that's right.

@Mycho - You've been able to run commands using runas (much like sudo) under windows since XP. Vista disables administrator by default and you have to authenticate any process that needs elevated rights to run under a different user context.

I thought linux doesn't have a kernel debugger...so all you have to do is to check for one and you know you have a rootkit ^^

(using debian stable for >1 year and still going strong)

Sorry, I don't run Linux as root. Why would anyone? To save typing your root password a couple times a day? Are (sane) people that lazy?

And I too am curious as to whether AMD is (as) vulnerable... Anyone know?

What, like the runas command?

re: "@AC 0310 - Yes, McAffee write viruses, that's right."

Uh, they do. As proof of code and to see if their heuristics will work.

And if there are some less desirable (from a point of view of social responsibility) employees, they can export these viruses.

Or is anti-virus the only place where everyone is trustworthy?

You forgot Vista's special security. Its not runas: you cant hack an OS thats been put back in the cardboard box.

Actually, I seem to remember seeing a demo about doing that a few years back. Booting off a liveCD with a Linux version of BitDefender to clean up your Windows.

If you follow this link you will see the proof of concept was released a while back.

http://www.linuxworld.com.au/index.php?id=1048371291&rid=-50

If I were an MS user I would worry about this a lot more than a Linux user as the vectors into an MS machine are more numerous !

This appears to more a design whoopsie in the x86 architecture rather than a Linux issue - anyone with a good knowledge of this care to comment and inform ?

In XP and previous versions runas is a pain in the backside to use -- and the tools under Windows are generally built in such a way that you seem to have to jump through hoops to get them to work with runas and even then they do annoying things like failing to save preferences. There's also the fact that anyone who needs to run as Administrator (or any other built-in account) needs the password for that account to do so.

>VmWare does a pretty good job of hiding itself from the client OS.

The vmware hypervisor or whatever you want to call it is visible to clients via special io ports on the virtualised processor. You can see how that works by looking at the openvm tools stuff vmware has released recently..... and this "exploit" is slightly different; As far as I can see it's basically about generating interrupts at a high enough privilege level (kernel debugging level) that you can do whatever you like, including trapping attempts by the running kernel to detect the rootkit. Unless this has some fairly extensive code to bind the kernel debugger part into the running OS I can't see how it's that useful scriptkiddies, if they can't manage a buffer overflow by themselves how are they going to work with something that requires knowledge of the inner workings of the processor to understand?

Actually, running a command using runas does not lead to the same level of access as running as an admin account. I don't know the full details, or how it differs, but I have had two occassions (acting as the defacto Windows sysadmin for my family at home) when a command would not run correctly when run with runas, but did when the same admin user was actually logged in.

I think it has something to do with the inheretance of the privilege by processes forked from the top level process, but it gave me a lot of grief until I noticed it.

In addition, things like auto-installers for devices probably won't work like this until you reverse engineer the autostart process on the install disk for a device. I would hope that the service that notices new hardware does not run with Administrative rights, otherwise you could ownz any Windows box with a rooted device install CD. Not good.

@Tom. OK you MD5sum the kernel, and all the kernel modules, and all the runtime bound libraries, and all the commands that you might expect root to run. Where do you store the expected sums? On the system? Off the system? And how about the MD5sum binary. Is that inviolate? Things like Tripwire and AIX's TCB have been doing this for years, but honestly, once you start thinking about it, you end up with recursive arguments, unless you have some trusted runtime environment like that proposed by Nigel.

To all Windows users. Have you actually checked to see how much of your C drive is actually writable by ordinary users? Do you even know how to check on XP home, or even know what the ACLs mean? Whereever I have seen Windows locked down hard, I have also found things like Word not being able to exit, because it thinks it has to write some information to a template or somewhere you don't have access to. I can't quote specific examples, but It's happend to me.

You might be surprised to find out how easy it is as even a normal user to change .dll files that are used by other commands.

I'm sure later versions of Windows are better, but why has it taken so long?

Windows' sudo-alike is called "runas" and works as you described (you can run a specific app or program with elevated privs inside your normal, user-level privs session.) It sucks, of course, and no-one uses it, but it is there.

If you do everything on linux whilst logged in as root, you are a retard.

It's that simple.

The extra features that AMD and Intel have added to the processor set include a new privilege mode on the processor, and some extra commands to enter this mode, and some commands that will only run in this mode.

It is like the normal/supervisor mode that most CPU's for multi-user OS's have implemented for over 40 years (think IBM 370, DEC PDP/11). It has just added an extra level ABOVE the operating system, together with a super-supervisor mode, which should normally be occupied by a Hypervisor (which treats OS images in the same way that an OS treats processes). The concept is quite simple to visualise if you think of the virtualised OS images, or LPARs, or whatever you want to call them as processes, and the Hypervisor as the OS.

There is supposed to be guarded access to this space, both at a memory level, and at program level. An OS is supposed to be able to request a service from the hypervisor, which can then vet the request and action it (or not). The OS making the request should NEVER be able to inject code into this space, and also should not be able to write into the memory in this space.

The sort of things that can be performed in this space include memory mapping to the OS memory space, scheduling of OS images, and inter-OS communication (used for virtual network and storage devices). Often, the hypervisor can 'look into' the memory space of a virtualized OS, and can monitor all traffic being sent between OS images. Scary, really.

If it is the case that an code in an OS, or even worse, and unprivileged process within an OS can compromise this divide, then there must be a serious design flaw in the CPU archetecture, or possibly a problem in the default state after IPL. This, in my view, shoud be a reason to avoid using this technology until it is fixed.

BTW, the earliest example of a hardware based virtualization system I came across was probably Amdahl's mainframe Multiple Domain Feature (MDF), which I used first in about 1985, although there were rumours of IBM doing a hardware version of it's normally software based VM earlier than this. The System/370 Advanced Function archetecture had hardware assists to allow VM to work better, include memory keying. IBM's software VM system first appeared in 1972.

Nothing is ever really new nowadays.

Your processor can be in 2 modes - user mode, and a privileged mode.

The privileged mode is required for an app to do certain hardware type things, but is only accessible after an interrupt.

i.e.

1: a program is running on the processor in user mode

2: the program triggers an interrupt, through a hardware exception like "tried to write outside its address space"

3: at interrupt, the processor looks at a table of pointers called "vectors", and starts running code at the location pointed to by the vector appropriate for the given interrupt IN PRIVILEGED MODE.

4: hypothetically, the rootkit overwrote one of these vectors or the code it points to to cause it to start the rootkit, letting it run without a visible owner process or somesuch.

Processors, AMD, intel, VIA, use a standard instruction set / structure called x86, with an increasing number of open standard extensions (SSE2 etc). The interrupt exploit is probably on the standard x86 instructions, so yeah, AMD is probably vulnerable, but intel ownes the rights to x86.

This may be slightly incorrect in the details, I'm not overly familiar with x86, but is probably 80% useful.

Without wanting to get into a "yes they do", "no they don't" argument. Here is the 1st hit from google if you look up "mcaffee write viruses" Point 2 is of interest.

http://www.avertlabs.com/research/blog/?p=71

x86 chips have "Rings", not just a flat user and supervisor layout. Ring 0 being where the kernel sits,.. The problem with this system is that when we fully virtualise a kernel it's code wants to run in Ring 0 too which isn't a good thing. SVM (Amd) and VT-x (Intel) get around this by letting the guest kernel's privileged code run but throw exceptions when it tries to do something bad like read memory that doesn't belong to it, or use instructions that it isn't allowed to... so the privilege model on a modern IA32/AMD64 processor is actually pretty complicated.

But I think that's beside the point as this rootkit uses the IA32 Debug Register (http://en.wikipedia.org/wiki/Debug_register)... The rootkit being implemented as debug exception handler which allows it total control over the machine (you wouldn't be able to debug a kernel otherwise). You would have thought however that the debug exception handler would have to be installed by privileged code i.e. the kernel. So by the point that this is installed the machine is fairly comprised already so this is just a way of hiding that fact and maintaining control over the machine.

The article says this doesn't work with SMP (would need to install handlers on all the running cores),... would it work when the CPU is in longmode? What stops it being ported to different OSes? Seems a bit flaky to me.

""In the old days, to attack a computer, you needed to 1) find a bug, 2) write an exploit, 3) run the exploit 4) hide yourself," Charlie Miller"

Actually, in the old days you put code in to the compiler source code so that it would add a backdoor to the OS as it was compiled. I guess it's too '80s for today's insecurity experts...

"Cunning tricks at the compiler level help catch coding mistakes, but it needs a thorough code audit to actually find all the flaws, some of which will be serious enough that no amount of voodoo will stop you getting rooted."

Yes, I couldn't agree more. My point was rather that on source-based distros everyone's binaries will be different enough to stymie many classes of attack, due the variety of features and options enabled at compile time and disparate version numbers involved. On binary distros everyone's binaries are likely to be identical, so an exploit targetting a specific distro is likely to work on the majority of machines running that distro.

@John Kelly

"Better get yer Mum to fit a lock to the basement window first ;)"

Next time I'm visiting I shall mention that to her, although I doubt it will affect the physical security of my many Gentoo servers which are all hundreds of miles away in secure hosting centres.

They're below the level of assembler, and even assembler is below the level at which I program and could hope to understand what is going on.

I'd like to see some certification method and accountability for what is going into the writable control store, not just a line saying "applying microcode updates" flying by whenever I start up my computer.

"Run as.." is not the same as "sudo", and I wouldn't even accept "sudo-like".

You can't install many applications that require Administrator-level system access using "Run as..". "Run as.." only works for applications which have been previously installed under an Administrator-level account. "sudo" can be used to do that installation, and then to run the application.

"Run as.." allows for the application to run without changing out of the userspace of the Limited Account user by giving Administrator access to the system elements required by that application that the user would otherwise have been denied access to. "sudo" allows for the application to run without changing out of the userspace of the Limited Account user by running the application in a separately-privileged userspace.

And my take on the rootkit is that it would be capable of living in any Intel processor, not just those that power Linux boxes. But maybe this article was aimed at Linux fanboys in support of Windows users who feel they have put up with too much bad press in the past decade.

On that note, is debugging mode required for everyday operation of the processor, or is it just something that did not get disabled before it left the factory? It seems to me that disabling processor debugging would mitigate this risk.

In regard to your missive:

----- quote -----

Immunity Inc. are based in Florida. As such, they are accountable under US law. If the yanks can extradite a UK resident (Gary McKinnon) for cracking, surely they are also capable of bringing someone to account who makes a rootkit toolkit to facilitate this crime? Or is being accessory to cybercrime not yet a felony?

----- endquote -----

Over on this side of the pond, the laws - and especially legal precedent set by the Courts -- often make a distinction between "making available" and "inciting illegal activity."

For example, in Electra v. Barker (US District Court, Southern District of New York; Case No. 05-CV-7340-KMK) -- a RIAA / P2P / copyright case -- the judge determined that (to paraphrase) making a copyrighted work available via P2P is NOT the same as offering to illegally distribute a copyrighted work (or encouraging others to illegally distribute a copyrighted work) within the context of the law as written by Congress ("Opinion and Order"; March 31, 2008; about page 18 and following).

And let's not forget Sony Corp. of America v. Universal City Studios, Inc. (US Supreme Court; Case No. 464 US 417; Initial hearing January 18, 1983; Reargued October 3, 1983; Decided January 17, 1984). In this case, the US Supreme Court held that a device or technology cannot be outlawed if it has substantial legal and legitimate uses. This case, again, was argued in the context of copyright, but the theory holds.

Immunity's DR product can be used for nefarious purposes. However, the software also has substantial legitimate uses: It is a tool that can be used by security administrators to see how well their computer networks and servers stand up to unauthorized penetration.

So the short answer is, basically, "No, Immunity will probably never be held as an accessory in the commission of Cybercrime."

Cheers...

As if I had another reason to say Linux has no freaking place on the home desktop. Let's see: GUI that doesn't use file extensions so that .doc could be an executable, check. Rootkits that can integrate themselves completely seamlessly, check. User bin directory that executes before system commands, check. Open source commands that anyone can make adulterated versions of, check. And a need to go root and re-enter your password often, check.

If our current "home" versions of Linux were, today, deployed on the majority of users' desktops, it would be a security disaster of epic proportions. It is too freaking easy to elevate privileges, and too easy to trick users into executing malware without enforcing file extensions that match file type. Malware writers would be all over it.

I am a professional Penetration Tester who uses Immunity Canvas as a part of my job, I feel that some people here are missing the point so I thought I'd clarify this for people who are interested in the topic.

1> Rootkit is not an exploit, you need to have root access on the remote machine to be able to install a rootkit. Rootkit's are designed to maintain covert access on the system.

2> It's not a windows v/s linux war all OS'es are equally vulnerable to rootkits, once compromised.

3> Canvas is a completely legit commercial python based pentesting kit just like core impact, this stuff is nothing new, They charge for the hard work involved in security research, hence the commercial support.

4> Holy Father had released commercial rootkits for Windows long back called hacker defender, it even has various editions, depending on how covert one wants the rootkit to be.

5> There are many much better linux rootkits available out there for people who know,.