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.

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

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

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.

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?

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?

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?

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 ?

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?

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.

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

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.

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

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