Attacking Multicore CPUs

Ant writes "The Register reports that the world of current multi-core central processing units (CPUs) just entered is facing a serious threat. A security researcher at Cambridge disclosed a new class of vulnerabilities that takes advantage of concurrency to bypass security protections such as anti-virus software The attack is based on the assumption that the software that interacts with the kernel can be used without interference. The researcher, Robert Watson, showed that a carefully written exploit can attack in the window when this happens, and literally change the "words" that they are exchanging. Even if some of these dark aspects of concurrency were already known, Watson proved that real attacks can be developed, and showed that developers have to fix their code. Fast..."

Fast?

[JordanL]

and showed that developers have to fix their code. Fast...

Ummm... no. In a world where the list of things that most developers need to fix is quite lengthy, some of which renders your average app unusable or even dangerous, fixing an exploit of a hardware configuration which has no proven virii in the wild is not at the top of the list.

Yes, it's important to be proactive. No, such a difficult and obscure attack is not something that is priority one.

Re:Fast?

[Anonymous Coward]

"No, such a difficult and obscure attack is not something that is priority one"

Thread one sends a command to the OS and knowing that it will take time x to complete

Thread two waits (x-d) before overwriting the buffer used to store the command (after the OS has checked it for validity, but before the OS has actually processed it)

what's obscure about that?

Re:Fast?

[Foolhardy]

If that's all it is, Windows NT (and its later incarnations like XP and Vista) aren't vulnerable because kernel components facing user mode are always expected to make copies of user arguments before they're validated and used. Since the NT kernel is preemptable this would be a problem even on single CPU machines because the thread handling the syscall could be interrupted by the scheduler to execute another thread while the first was validating the arguments. Only data that is treated opaquely (e.g. a buffer to write to a file) can be accessed directly safely. This has been known and accounted for since NT was originally designed. Of course, that doesn't rule out the possibility of 3rd party developers not following the rules.

From Common Driver Reliability Issues: User-Mode Addresses in Kernel-Mode Code [microsoft.com]

Be prepared for changes to the contents of user-mode memory at any time; another user-mode thread in the same process might change it. Drivers must not use user-mode buffers as temporary storage, or expect the results of double fetches to yield the same results the second time.

Re:

[legirons]

"Windows NT (and its later incarnations like XP and Vista) aren't vulnerable because kernel components facing user mode are always expected to make copies of user arguments before they're validated and used"

So Windows has a coding standard that says this shouldn't happen. I don't see how it necessarily follows that Windows isn't vulnerable. You're assuming that all the kernel-mode code in Windows is following the standard/reccomendation that you refer to. Let's say that even one occurance of code that do

Re:

[Foolhardy]

What I should have said is that the design of Windows NT isn't vulnerable. The article seems to be implying that this is a new sort of vulnerability, but it's not for NT because its preemptable nature has always required this to be done properly to be secure. No, I haven't personally verified the source code because I don't have access to it. Still, the core kernel team that writes such code has a good reputation for writing secure, correct code. Of all the security vulnerabilities I know of on Windows, onl

Re:

[adisakp]

Since the NT kernel is preemptable this would be a problem even on single CPU machines

From the Article (emphasis mine):

"I was able to successfully bypass security in many system call wrappers by creating unmanaged concurrency between the attacking processes and the wrapper/kernel. This was possible on both uniprocessor systems and multiprocessor systems."

Re:Fast?

[Tim C]

Correct me if I'm wrong, but that sounds awfully similar to a race condition (it clearly isn't one, but it certainly *looks* like one), which would seem to me to mean that it would have all the same dependencies on the vagaries of system load. I'm not saying that this would be impossible to pull off, just difficult to do so consistently.

Of course, depending on what you're actually trying to achieve, consistency may not be an issue.

Re:

[Wavicle]

Thread two waits (x-d) before overwriting the buffer used to store the command (after the OS has checked it for validity, but before the OS has actually processed it)

Could someone explain this to me some more. In order for thread2 to write to buffer1, there must be a page table entry mapping buffer1's physical address into thread2's virtual address space.

Are the operating systems allowing thread2 to arbitrarily change its PTEs? That sounds like the problem right there.

Re: Fast?

[Dolda2000]

It's obscure because, as far as I know, all the standard syscall implementations on both *nix and NT copy the contents of user-space buffers into kernel space before doing anything at all with them, including validation. From what I can tell from the article, the problem is limited to syscall wrappers, and how often are they even used? Sure, there are several implementations (all whose names I've forgotten), but how many people actually use them outside of doing research on them?

The blurb mentions Anti-Vi

Re:Fast?

[JoelKatz]

This has nothing to do with multi-core CPUs. This exact same attack would work on the run-of-the-mill SMP systems that have been around for decades. Multi-core CPUs just make SMP systems more common.

Re:

[petermgreen]

more common is a HUGE understatement, multicore CPUs have brought SMP from something servers and high end workstations sometimes had to something that all but the lowest end computers sold today have.

Re:

[ivan256]

"Almost" SMP.

Two cores, one cache.

Or sometimes, two cores, two L1 caches, two L2 caches, one L3 cache.... Either way, the only thing symmetrical about them are the execution units, and not the whole processor.

Re:

[petermgreen]

To me SMP means two processors which operate in the same way and have equal access to main memory. Whether they are on the same die and what cache is or isn't shared seems mostly irrelevent as long as there is a cache coherency system in place for any non shared caches.

Do you have a different definition and if so what is it?

Re:

[ivan256]

I think we have largely the same definition. What you're saying is that NUMA is the opposite of SMP. I think that is a perfectly good definition.

I was being a little more specific though, probably to a fault. To me, SMP implies that you can schedule workloads on the CPUs as equals. If you have two shared-cache multi-core packages in one system, however, the system has some NUMA-like scheduling behaviors.

Re:Fast?

[g0dsp33d]

I agree. If you read the article, you'll notice that such attacks as "This was possible on both uniprocessor systems and multiprocessor systems." Also, it has been known since at least 1998. I'm guessing its not that big of a deal, because exploit code would be difficult, there are easier targets, and lastly because anti-virus software could probably still look for the code(not in real time, but only when its infected on disk or transit).

Re:

[daem0n1x]

One day all developers will have to put a leash in every single electron that runs inside the computer.

Re:Fast?

[Anonymous Coward]

Perfect, another moron who thinks idiot is plural.

Re:

[Anonymous Coward]

Maybe because he said "think" instead of "thinks". Good job being a grammar nazi!

Re:

[thePowerOfGrayskull]

"another idiot" == "one idiot" which is not a group, but a singular individual. Case in point: if what you said was correct, shouldn't you have written "YMI (Yet more idiot)"?

Sidebar re Virii

[davecb]

Of course it's a word, it's a portmanteau word. A colleague and I made it up years ago, to see how many folks would thnk it was the proper latin tag for the little monsters.

The proper latin plural for virus is, if memory serves, virus.

--dave

Re:Sidebar re Virii

[Nazlfrag]

quote>The proper latin plural for virus is, if memory serves, virus.

I'm a viroligist, you insensitive clod, and besides the obvious plural for virii is viruseses. Duh.

Re:

[Protoslo]

Although it is a good guess, sadly your assumption that virus is in the fourth declension is also totally wrong. Perversely enough, it is neuter in the second even with the '-us' suffix, so the plural is actually 'vira.'

As for 'virii,' well, my mind drew a blank, but William Whittaker's Words claims that virii is the genetive singular of 'virium,' (verdancy), the noun form of 'vireo.' As for whether that form was ever actually used, though...the perseus project server appears to be melting down, or I woul

Re:

[davecb]

Of virus and the latin plural of a different
declension (the plural of masculine and feminine
words ending in -ius)

--dave

Re:

[Andrew Tanenbaum]

I'm not convinced that "virii" counts as a portmanteau, which generally requires that the sound and meaning of two words are preserved.

Re:

[davecb]

Good point...
What's a proper term for mock latinate, I wonder (;-))

--dave

Re:Fast?

[Sique]

Main problem: the latin virus, meaning 'slime' or 'poison', is a singularitantum. So there is no historical plural for virus. That allows us to just make one up. And we should make it so, that it doesn't interfere with the plural of vir (man).

Re:

[Floritard]

And we should make it so, that it doesn't interfere with the plural of vir (man).

"There is another organism on this planet that follows the same pattern. Do you know what it is? A virus. Human beings are a disease, a cancer of this planet. You're a plague and we are the cure."
- Agent Smith

Re:

[Jesus_666]

By the way, German doesn't have that problem as we tend to germanize leanwords - "Virus" (vee-rus) uses the normal German rules for pluralization, turning into "Viren" (vee-ren). Of course that doesn't work too well with English - "virs"? "vires"? Actually, I'm fine as long as someone doesn't come up with "virora" while on a glue bender.

Re:

[ConceptJunkie]

That would be true for "virii" only if the singular were "virius".

Re:

[joss]

D, [http://www.digitalmars.com/d/] hmm elegant perhaps but not flawless. There are reasons why the undeniably flawed C++ is more popular.

err, system call wrapper runs with kernel privs?

[Anonymous Coward]

Does the system call wrapper run at kernel privileges (or some elevated level giving protection from the caller), or at the privileges of the calling process? If the latter, it is of course worthless. If the former, I'm not sure how you can modify values stored in privileged space before they're sent off to the original code.

Re:err, system call wrapper runs with kernel privs

[DrSkwid]

Yeah, that'll be why the example exploit code fails.

Re:

[dgatwood]

Unless I'm misunderstanding the issue, this seems like a completely irrelevant exploit. More accurately, it seems to be about the least efficient way possible to achieve this goal. If you already have injected virus code running in a separate thread inside a process, you don't have to intercept the system call and overwrite the data at all. You can just ask the system to grant write permission to the TEXT pages and change the system call to call into your own function that mucks with the values, calla th

Multicore?

[Anonymous Coward]

How much does the hardware platform affect the attack?
Multiprocessor systems are marginally easier to exploit since they do not require forcing kernel context switches via paging or other techniques. However, I was able to successfully bypass the same wrappers on uniprocessor systems. I did my experimental work on Intel hardware, but they should work across a range of hardware architectures and configurations.

Again?

[DeHackEd]

Looks like a variation (or maybe a dup) of this [slashdot.org].

Re:

[ByTor-2112]

Yes! I knew I'd seen this before somewhere. Now I can stop trying to track it down!

Re:

[fluor2]

Same here. Cambridge, this is a dupe.

Damn it

[Frogbert]

You see, Its these kind of computing professionals that make me feel like a fraud when people call me a computer genius.

Stop raising the bar you tool!

Re:

[CastrTroy]

Well, as a software developer, most laypersons would probably refer to me a computer genius, but compared to this guy, I am probably anything but. However, I can see how this happens. I'm not big on cars, but the mechanics who fix them seem to work wonders, and be car geniuses. Some of them anyway. There appears to be a lot of mechanics who all they can do is read the print out from the computer and then do a bad job at fixing it. Just like a lot of bad programmers. Anyway, that's another discussion.

Re:

[Joebert]

I'm not really a Nerd, but I did stay in a Holiday Inn Express last nite.

Re:

[CastrTroy]

That kind of hits on my philosophy that all people are geeks. All people are geeks about something. Be it sports geeks (aka jocks), car geeks, hair geeks, computer geeks, math geeks, wilderness geeks, or knitting geeks. Its just that for some reason, anybody who does anything intellectual as a hobby seems to be viewed as a special kind of geek, and looked at as strange or unusual.

Re:

[PopeRatzo]

we look back on the works of Dijkstra, Hoare and Knuth.

Weren't they the infield for the 1932 Yankees?

Re:

[Jesus_666]

No way, man. Edward Dijkstra built the first navigation system, Tommy Hoare invented the algorithm and Ronald Knuth wrote the Morris-Pratt worm, which later evolved into ILOVEYOU and Sobig.

Ha! And the professor had me fail the Computer History class! I still know everything!

a dozen anti-virus companies just squealed in glee

[Anonymous Coward]

(Insert Brand Name) Anti-Virus 2008: Multi-Core version (+$25 extra per core)

Neither submitter nor editor RTFA...?

[perrin]

It seems that neither the submitter nor the slashdot editor read the article in question. The attack is not specific to multi-core systems, and it works only against programs that wrap system calls to add additional system protection. So it does not pierce through standard OS security, and you already need to have execution privileges. The writeup is just hype and FUD, IMHO.

Re:

[Joebert]

It seems that none of the submitter, the slashdot editor, or three quarters of the people who comment, read the article in question.

I fixed that for you.

Re:

[The Living Fractal]

Wait, there was an article?

Re:Neither submitter nor editor RTFA...?

[Richard W.M. Jones]

It's also old news [slashdot.org].

The SELinux guys debunked it [livejournal.com] over a month ago.

Rich.

Re:

[Anonymous Coward]

He didn't debunk it; he agreed that system call wrappers have all kind of problems and described Watson's work as a "good paper". He then pointed out that SELinux doesn't use system call wrappers, so it doesn't have these problems. That doesn't mean the problems aren't real elsewhere.

But I agree it's old news. It was old news ten years ago. Security has to be in the kernel. Period.

Re:

[GooberToo]

In other words, it's a problem if you use anti-virus software. Use of anti-virus software which hooks system calls is actually creating an attack vector.

Re:

[cryptoluddite]

and it works only against programs that wrap system calls to add additional system protection. So it does not pierce through standard OS security, and you already need to have execution privileges.

Or one could look at it as standard OS security not being flexible or modifiable enough for the real world. The reason why these syscall intercepts in-process or in another process are used is because the system security doesn't do what is needed and can't be modified dynamically. The reason these things exist is because it is far easier to do these checks in user-space. I would certainly say it is a technical weakness that one has to be a skilled kernel developer and create a patch for the kernel and r

Re:

[Fweeky]

Erm, no, you don't need to be root to exploit these attacks, you just need to be in a situation where some security is provided by syscall wrappers. Such wrappers are sometimes used to provide an additional layer of security for applications and services; providing additional limits to what files can be read and modified, what executables can be ran, where sockets can be bound and so forth, and importantly, logging when attempts to breach these policies are attempted. You're exactly one buffer overflow aw

The example they give is wrong

[A beautiful mind]

to bypass security protections such as anti-virus software

Anti-virus software isn't by any means "security protection", especially the type that works on a heuristical basis. They are simply long lists of known to be disadvantageous programs and a daemon that tries to match the list to data on the system.

Sure, they might offer some kind of bandaid for systems operated by people who do not have the necessary knowledge to operate a computer, but it is first and foremost a security theater and it does more harm than good by providing a false sense of security.

There are two solutions to the problem by the way. The former is educate the users and the latter is to switch to linux. No, seriously. The important part isn't linux, but switching away from a monoculture preferably to a desktop environment that is ruled by at least 3-4 systems that are different from each other and they are interoperating in well defined ways with each other. That way, you can get the platform (the systems it can possibly infect) down for a virus to a threshold where the percentage is simply too low for it to be able to spread.

Re:The example they give is wrong

[tgd]

There's a billion PCs in the world -- if you think four OS's sharing 25% of that market makes it too small to be of interest to criminals, you're nuts.

Monoculture is not the problem, although its a convenient flag to fly when "free as in beer" and "windows sux0rs" runs out.

Re:

[GreatBunzinni]

You seem to be a bit confused as you missed the point entirely. The point is that if there is a monoculture then a single virus can infect and disrupt the entire market. On the other hand, if there isn't a monoculture, even if a virus spreads violently and wreaks havoc through one OS it will only affect that one OS's market share, leaving all the others unaffected. That would mean, in the 4 OS scenario, that a violent outbreak of some malware would only affect 25% of the entire computing universe.

The point

Re:

[tgd]

Nice try, but just FYI I ran Linux as my primary OS for over ten years until I switched to OSX, and still have a half dozen server boxes and three desktops with it here. There's one and only one Windows box in my house and thats my girlfriends' Dell which she has because a Mac was too expensive.

Finding blind fan-boi-ism and ignorant arguments annoying doesn't make someone a Linux hater.

Re:The example they give is wrong

[A beautiful mind]

Currently in this monopoly culture, the platform (systems a virus can infect) is around 35-40% at best. There are patched systems, way too old operating systems and incompatibilities between different versions of windows, so that even if Microsoft has an OS monopoly on the desktop PCs, it still does not translate into totally monolithic platforms a virus can spread from. (Paradoxically if everyone would run a subscription based OS with updates aka windows live it would make the security situation in IT much much worse. Possibly a doomsday kind of scenario for IT.)

If an OS has 25% marketshare, it would translate to less than 10% of effective platform because of the incompatibilites between old and new versions, sane default settings and because at least some people patch their systems. As far as I know you only need to go below 10% or so to make it infeasible for a virus to spread. The virus would have to be very good at propagating in order to be able to spread at all. Think of the 10% as the number of pcs you could infect in theory, but of course if we for example talk about propagation by worm style or by spam, the real percentage is much lower since there are additional boundaries to pass, like spamfilters, even simple NAT home routers, etc. There are simply too many systems inbetween that the virus would waste time on trying to infect, so finding vulnerable systems is hard.

Thinking about 25% in this sense suddently makes more sense doesn't it?

Re:

[legirons]

If you really think that such diversity is useful for security (you'd need to have several million type of operating system all incompatible with each others' code and scripting languages for it to be a useful block to worm transfer (and 50 different versions of redhat with the name changed doesn't count)) - then suddenly each OS has only a few users, so nobody to help you with problems on it, and nobody to write software for it.

(you thought it was hard getting games to run on linux - try getting games to r

Re:

[Frozen Void]

Would you say this if the monoculture was OpenBSD?

Re:

[trifish]

especially the type that works on a heuristical basis. They are simply long lists of known to be disadvantageous programs and a daemon that tries to match the list to data on the system.

I wonder why that incorrect post is modded +5.

Heuristic scanning is the opposite of "long lists of known to be disadvantageous programs".

It is a form of pro-active security analyzing the behavior and features of an unknown program WITHOUT any lists of known viruses. For example, does the program hook the keyboard and adds i

Re:

[A beautiful mind]

Heuristic scanning is the opposite of "long lists of known to be disadvantageous programs".

I'm aware, the phrasing was maybe a bit confusing. I should have written something to the effect of "even the traditional list based method is quite inefficient and broken, but heuristic scanning even more so". The reason is because while in the case of lists it's trying to identify programs that cause harm, in the heuristic case it is trying to judge _intent_ of the programs.

A virus is just simply a user mode appl

Re:

[A beautiful mind]

Yes. Not having a mainstream OS to replace Windows with, but instead fragmenting the operating system landscape would eliminate a lot of problems. Pretty basic disease control principle: breed and use multiple types of plants and animals, so that any single disease can't kill off everything.

Re:

[Mr. Shiny And New]

Having a more variable ecosystem for operating systems would make viruses spread more slowly but it wouldn't eliminate the problem and would increase all other costs: costs of software development, costs of administration, costs of training, costs of inventory management, etc.

In the end abstraction layers would form where viruses could still spread. If everyone had a unique OS, but ran a web browser that supported Javascript, then people would develop Javascript viruses.

Not sure that this applies to Windows...

[tjstork]

The article talks about wrapping OS calls to any process, and I don't think that's something Windows can really do. Yes, there is a limited hooking facility, but I don't believe there is anything that allows a user app with admin priviledges to effectively create a subsystem on top of a subsystem, which is what this application does. There are root kits that do this sort of thing on a single call, but arranging that is rather laborious. Really, the Windows kernel just isn't accessed with a single syscal

Er, that's an OLD attack

[davecb]

It works on any multiprocessor, including an
IBM 360/168 mainframe, where I first encountered it.

--dave

Re:

[davecb]

Right!
The room was dominated by the 360 (/75,
I think) so I misassociated the little
168 with it (;-))

--dave

News flash!

[achurch]

In a multitasking system, you can read and write the same memory space at the same time! . . . Oh, I guess it's not news after all.

Seriously, this is just Yet Another Race Condition. As long as you follow the rules of multithreaded programming (which for syscall wrappers means copying your arguments, since you can't negotiate mutexes with the caller), this is a non-issue.

Neeext!

Re:

[phasm42]

Mod parent up.

This is only a problem if your syscall wrapper didn't take this into consideration. If you're writing a syscall wrapper for security reasons, you don't pass parameters that the original caller still has write access to.

Parallelism

[Peaker]

This should probably even work in a single-processor setup, with ordinary threads, because the user-space system call wrapper is most probably pre-emptable (How would it prevent preemption?) and thus a thread-switch can occur during the syscall wrapper code. It may be less probable, but careful timing and multiple attempts can probably achieve this same exploit on an ordinary single-processor setup.

Re:

[Peaker]

Are you sure the system call wrappers in question are in kernel space? The article gave me the impression its purely a user-space technique (I was guessing it was done via some sort of code injection or such).

If it is kernel-mode, how does it use another thread of execution to overwrite the temporary copy made in the kernel?

Misleading article

[Anonymous Coward]

From the title it seemed clear to me this article was *supposed* to be about exploits unique to SMP hardware. Yet all it really is about is generic software race conditions totally unrelated to SMP and its concurrency model.

For those of you who didn't read the article:

"I was able to successfully bypass security in many system call wrappers by creating unmanaged concurrency between the attacking processes and the wrapper/kernel. This was possible on both uniprocessor systems and multiprocessor systems."

I wi

Well, it was almost English.

[_Shorty-dammit]

That summary made my head hurt. Stupid taco.

Rediscovered again

[kabdib]

Nothing really new here.

Other attacks include DMA into buffers already provided to the kernel (lots of fun with async disk and network I/O), GPU writes, OS callbacks (depends on the OS in question), and even plain vanilla threads.

The kernel (or whatever secure subsystem you're talking about) needs to copy and verify parameters. This stuff has been known for decades. That doesn't stop weak software from being written, but it does give old farts like me a chance to kvetch :-)

Ahem.

[tomstdenis]

FTA I was able to successfully bypass security in many system call wrappers by creating unmanaged concurrency between the attacking processes and the wrapper/kernel. This was possible on both uniprocessor systems and multiprocessor systems.

What's this about attacking multi-core processors?

The processors aren't broken, you could race a process in a uni and SMP system just the same. And in reality, your syscall security should be in there kernel itself, where any copies taken of data are passed internally to

How hard can it be?

[Chabil Ha']

Even if some of these dark aspects of concurrency were already known, Watson proved that real attacks can be developed...

Elementary, my dear Watson.

Similar attack exists on single CPU with DMA I/O

[karl.auerbach]

Way back in the 1970's folks I worked with were hired by IBM to form a tiger team to attack VM/370. (Virtual machine OS's have been around since the 1960's.)

They were able to crack the system by setting up a DMA based read. Then they called the kernel with some kernel call parameters. The kernel checked the parameters. And then the DMA input rolled new values onto those parameters.

This, of course, took some careful timing.

And it relied on kernel weakness - the weakness of leaving the user parameters in

RTFA - not SMP specific

[sofar]

I was able to successfully bypass security in many system call wrappers by creating unmanaged concurrency between the attacking processes and the wrapper/kernel. This was possible on both uniprocessor systems and multiprocessor systems.

So, this doesn't protect UP systems at all. preempt already exposes you to these kind of concurrency issues, and one can only assume that pretty much any RT OS also is vulnerable.

Vague; unsubstantiated..."race" conditions? oh my!

[lpq]

While there are potential problems, he doesn't say which systems.

The article mentions *nix based systems, but talks about Anti-Vir sw that layers on top of the
OS. The layered AV SW, sounds like a windows problem.

While there are race conditions possible with many security solutions due to the fact that they are not bound into the kernel, none of the problems are new with "multi-core" than with other "MP" machines (computers did have multiple "Cores" (CPUs) in the past -- just not on one chip).

The article is

Re:

[ByTor-2112]

That's you, though. Most people believe that because they have anti-virus software they CAN safely run anything. I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS. Intel and AMD have to love this arms race.

Re:

[headkase]

You're ignoring the installed base of the OS. When Linux is as popular as Windows then the people writing malicious software will target it as well. They're doing it to make-money/steal-information off of you, Windows is the target now because it offers the highest return on investment. Once the Linux platform is widely popular then security tools will become relatively more necessary for it too.

Re:So what?

[TheRaven64]

When Linux is as popular as Windows then the people writing malicious software will target it as well.

And that's why the sensible people will also use Macs, BSD, Haiku, ReactOS, etc. A monoculture is easier to attack than a heterogeneous computing environment.

Re:

[MadMidnightBomber]

Fuck no. I could deploy a thousand Linux machines and never have to use the same distro/kernel/config twice. Linux rulez man!

Re:

[DrSkwid]

Yeah, just wait until people run non-Windows machine as web servers and the like, it's gonna be chaos !

Re:So what?

[Warbothong]

I remember watching an episode of the BBC's (very Microsoft dominated (as in, something major happens with Linux or Ubuntu or whatever, nothing. Some low-down Microsoft employee makes a comment about something he thinks might possibly someday become slightly relevant to some tiny niche and they spend 10 minutes on it)) Click program ( http://www.bbcworld.com/click [bbcworld.com] ) and they had some "experts" (read: marketing guys) saying what the benefits of dual-core CPUs could be. All they could come up with was "You can use one core to do all of your normal activities, and use the other core to run antivirus and antispyware and firewall software constantly".

I almost cried.

Re:

[ByTor-2112]

I saw the same thing, and I had the same reaction. I still think of it every now and then and having another little laugh to myself.

Re:So what?

[prator]

Congratulations! This is the first time I've ever seen someone use nested parentheses in non-code. You win a set of extra parentheses keys (because (as I've noticed) you seem to use them a lot).

Re:

[mrchaotica]

This is the first time I've ever seen someone use nested parentheses in non-code.

You must be new here, 'cause I see it all the time.

Re:

[corsec67]

Yeah, apparently people speak with a lisp a lot....
(Anyone who has used lisp would get the joke I was trying for)

Re:

[phantomfive]

Dude, it's all about delivery.

Re:

[Alsee]

This is the first time I've ever seen someone use nested parentheses in non-code.

This from a Slashdot reader with a 5 digit UID?
Either you're lying just so you could make the joke, or Alzheimer's is setting in.

-

Re:

[prator]

I do read a lot more digg than I use to. That is probably the same as having a debilitating neurological disease.

Re:

[drsmithy]

I still find it an amusing shame that people are so willing to accept the huge performance penalties of anti-virus and now anti-spyware/adware for their utterly broken OS.

AV software isn't protectng your from problems in the OS, it's protecting you from problems in the user.

No amount of OS security can stop the user from deliberately doing something stupid - nor should it.

Re:

[TomV]

would only work on windows boxes anyway

Now, I know nobody likes to be caught Reading The Fine Article, but it's maybe worth pointing out that according to The Fine Article, the exploit was demoed on Linux, FreeBSD, NetBSD, and OpenBSD. No mention of any other specific OS, though Watson did say "They should apply equally well on other operating systems".

Re:i wouldnt worry too much

[0racle]

It's called a race condition and can/has affect every OS that has SMP capability.

Re:

[0racle]

BTW, here's that missing 'ed' from the previous post.

Re:

[rthille]

Not true. Messaging passing OS's and even BSD's without syscall wrappers enabled don't suffer from the problem.

Re:i wouldnt worry too much

[sjames]

It's not even restricted to SMP. Some of the more clever hacks will work on a uniprocessor system by retrying until a context switch happens at just the right instant (or wrong instant depending on your perspective). They may stack the deck in their favor by arranging for a function call to cause a page fault. It's certainly easier to exploit with multiple processors.

The one certainty is that this form of attack is nothing like new.

Of course, many syscall wrappers can be bypassed by coding a syscall directly in assembly language rather than calling a library function.

The crux of the problem for ptrace based systems is that some syscall parameters are stored in user memory. Consider the open call in an environment using ptrace for security. I write a multi-threaded app and create a buffer holding the filename. I set it to "/some/path/thats/ok" and call open. The ptrace process is notified of the call, accesses the filename parameter in my thread's memory and decides it's OK, so it calls ptrace to allow the syscall to happen (rather than nullifying or killing my process).

IF my second thread can change the filename buffer to "/some/path/I/shouldnt/be/allowed" between the moment that the tracer decides it's OK and the moment it calls ptrace to allow it , the kernel will open the file for me and I have bypassed security.

On a uni-processor system, I might have to make a great many attempts, but with persistance, eventually my second thread might get scheduled at just the right moment to make the change. If I succeed once, the billion failed attempts won't matter.

The central problem in this instance is that ptrace was intended to be a debugging interface and not a security measure.

Solving that problem could get quite complex. If the security measure must also validate data written (which could potentially be several GB), the kernel would have to make sure that no thread in any process that has access to the memory the syscall covers can be scheduled AND that no other ptrace parent of those threads can be scheduled. It can do that by walking process structs under a lock (expensive) or temporarily marking the affected pages R/O and blocking on a fault (also expensive on most archetectures). Even if such a measure is taken, it shouldn't apply to a normal ptrace since it would significantly change the behaviour of a program being debugged.

The difficulties above are why all files that can be accessed by a system that can access classified data must also be treated as classified no matter what they are. Otherwise a badguy might manage to stuff a blob of top secret data into an unclassified file for later retrieval. Just imagine the nightmare of attempting to track classification level page by page and proving it can't do the wrong thing.

It's related to the reason that no DRM scheme can ever provide absolute protection against a sufficiently determined copier.

If the security is limited to parameters that have a more sane maximum size (such as a filename where MAXPATHLEN is a set value), the kernel could copy the parameter first and provide it to the tracer process using a different syscall.

From a more theoretical POV, any OS kernel that unwisely relies on a parameter in userspace not changing between the time it validates access and the time it fulfills the request can even have it's internal access controls violated or end up getting crashed on an SMP system. That's one reason why modifying a kernel meant only for uniprocessor systems to support SMP is VERY non-trivial.

Re:

[geniusj]

That's like saying: "Oh, this is just a race condition, nothing new here . . ." These are incredibly broad classes of exploits. And what he's talking about, while a race condition, is almost its own class of exploit because of how broad its scope is.

Re:

[geniusj]

I'll also add that a rootkit isn't traditionally an exploit at all. It's usually a backdoor or series of backdoors (sometimes as well as tools/kernel mods to hide itself) that allow an attacker further or continued access to a system that he has exploited in some other way. So it's not what you use to get in the first time, but the times following.

Re:

[Florian Weimer]

The first submission lead people to believe that it was some kind of vulnerability in OpenBSD when its really a whole class of security problem affecting any kind of process that attempts to trap the system calls of another for the purposes policy verification.

It's not a new class, CVE-2006-0457 [nist.gov] is in the same category, for instance.