There's certainly a huge incentive for it to be broken--how many botnets will be set to work on it as soon as Vista is released?
Barring any revelations about P and NP that would have consequences far more broad than MS's certificate being broken (many FAR, FAR more dire consequences (as essentially all crypto from the last few decades is based on the assumption that P!=NP) than just MS having to decide whether to revoke its certificate), I think you can sleep well. There's an outstanding $30,000 reward for anyone who can factor a given 704-bit number. A year ago a team finished putting 30 processor-years (2.2 gHz Opterons) to breaking a 640-bit number. These signatures are probably 1024 or 2048 bits. This is not an easy problem by any means. You could probably throw today's computers at it for millenia and be little closer to breaking MS's certificate.
And I don't like the possibility that, if MS had a dispute with a hardware vendor, they could threaten to revoke the certificates to the vendor's drivers that were already in the field...
reverse engineer and slide your code inside the signed driver.
I'm gonna mostly let this go because someone else already pointed out that this is more or less impossible. If you change the binary, then the signature is no longer valid, so you have to change the signature to match. Doing so would take... oh... we'll be (very incredibly) optimistic and say a millenia. (Barring any revelations that P=NP after all.)
You could replace the loader that verifies the signatures, but that would require a reboot into another OS. (Assuming Vista has adequate protections of the loader while it's running.)
is it that hard to put in a real filesystem security
You mean like they had in NT 4?
I'm not sure if you've noticed, but at least the professional version of XP, as well as 2000 (and probably NT 4 and maybe 3.51) support far more finer-grained priviledges on the filesystem than any Unix system I've seen. (Including those that support ACLs.)
and make it so that only the administrator can write to system directories and make the user not run as admin???
Well, I agree that it is not really honest to use DRM here, they are not totally unrelated. The idea is that the DRM in Vista uses kernel support to ensure the no-copying bit. But if you can load your own kernel-mode device drivers, you can do anything, including defeat the DRM schemes. So the driver signing issue protects against both DRM defeation attempts and security issues.
You can self-sign drivers during testing. I don't know the procedure that you have to go through or what UAC prompts pop up. Some other people in this thread say you can install your own root certificates, so that would at least be one approach. You can also apparently turn off the protection during boot from the F8 menu.
Are you aware of the performance penalty of this hardware VM? How does it compare with, say, VMware Workstation?
VMWare produced a paper comparing their binary translation to hardware VM, and most of the benchmarks had the HW slower -- and we're talking like an order of magnitude slower -- than the binary translation. Even the one benchmark they had with second-generation technology in the Core was several times slower than VMWare.
I could see them making something like this as essentially an advertising thing, but I can't imagine it'd be complete BS. And if it's not, it seems like any virtualization attempt has a huge obstacle to overcome in not making the computer seem slower. Because if mine started to act like a vitual machine in VMWare, I'd certainly notice...
What if it just flat out prevents you from modifying the pagefile in the first place?
There are a couple approaches here, with varying degrees of success.
The first is to just prevent access through the API. Check that the filename you're opening isn't the pagefile. If it is, make it readonly. (Or better still, disallow access entirely. Too many security vulnerabilities sit here; there's a lot more you can do than just get your driver loaded.)
The second is to prevent I/O accesses directly. There essentially has to be a way to read raw blocks through the API, because hard drive recovery programs do that. (EDIT: I'm looking at the Blackhat Blue Pill presentation, and this is what they use to get into the pagefile in the first place.) So block that off for the blocks that are in the pagefile. If you locate the pagefile at a known location, say starting at the beginning of the disk, this is easy and fast. (And can be combined with preventing modification to the loader that checks kernel signatures in the first place.)
Both ways assume that the kernel is pure (so your hard drive driver won't allow access or try to do things malicious itself) and bug-free as far as these checks are concerned.
(Oh, and the paper also says that it's possible to make a blue pill that's undetectable, even offline, and even if you know the code and can look for signatures. I think this is impossible.)
And how are you going to do that if the OS prohibits any I/O activity that go to that (those) disk sector(s)? This is very probably not an impossible task to do well. (Though whether Windows does it is an entirely different story entirely.)
And don't say "boot into another OS" because telling the user to "reboot into another OS and run this" is not exactly a viable infection method. If the OS actively protects against this, you *have* to find an exploitable bug in it, or find a way to get into ring 0 to run I/O code itself.
You know, there's a reason no operating system in common use does this, and it's because it's too slow. Doing a ring change takes some time... even a syscall instruction takes a couple hundred cycles.
I shall quote the C++ standard, because that's what I have.
Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.
(ISO 14882:2003, clause 5.4)
The above code prescribes two modifications; one from the ++ and one from the assignment.
i = v[i++];// the behavior is unspecified
Here you would also think that the behavior should be specified completely: i++ has to be evaluated before the array index can be taken which has to be loaded before it can be stored in i, but this isn't necessarily the case.
There are sequence points at function entry and exit, which don't apply here, and at the end of each statement.
I'm pretty sure that my reading is right (if you (regular) Google this expression you'll get a number of hits saying it's undefined, including a couple on the C faq (in particular, 3.3), but I'm not exactly an expert, so if you can cite sources that say more than "well, it should be this way because if you think about it..." I'm open to being proved wrong.
However, I think that the threat model is still SUBSTANTIALLY narrowed by signing the kernel. Note in your point 4 you say that you can do it without Windows's consent: if you're a malware author, what are you going to do? Say "reboot your computer into another OS and then run this"? Most users won't even know what you're talking about!
Assuming (and yes, these are big assumptions) that the kernel takes precautions of not allowing anyone to overwrite the loader, including other pieces of kernel code, then you can't do it from a running system; if you can't do it from a running system, it's for all intents and purposes impossible if your goal is to spread malware.
Now, if you can protect the loader, you can protect the kernel image itself; but the latter presents a much larger target. Layered security. There's no drawback* for a closed OS of checking signatures of the kernel except a slightly longer boot, and it adds an additional layer of security.
(* This is a separate idea from requiring drivers from being signed. You could sign the kernel itself and not require drivers to be signed, and use another mechanism to try to ensure that they aren't malicious.)
Finally, once trusted computing spreads its ugly tentacles, the protection of the loader will be hardware enforced, and then you're gonna have a REAL problem.
You just mount your disk under linux or whatever and replace ci.dll with one that always returns "yeah this file hashes OK". Could probably do it with a hex editor.
So you're a rootkit author... what are you gonna do now? Say "reboot your computer into another operating system so I can install myself"?
It is possible to make corrupting the kernel VERY hard to do from within the system, and the first step is to restrict what runs in ring 0. Cryptographically signing the legitimate kernel code is a good part of the solution if you can follow it up. (And there's a lot you have to follow it up with. But I think you could do it without degrading the usability of the system much.)
I don't think that MS's solution of signing drivers though is necessarily a good one on a few levels, even if you ignore the issue of whether they are trying to exert control for a less-than-altruistic purpose, and I don't particularly trust them to follow up with the other things that need to be done to keep a secure kernel.
memset signature looks like this: memset(void *s, int c, size_t n). The semantics are that it copies the lower byte of c into all of the first n bytes starting at s. This is used to initialize structures (e.g. memset(&s, 0, sizeof(s)) ) and to zero out sensitive buffers after they're used (e.g. memset(password, 0, BUFLEN)).
The problem with the code pointed to is that the last two parameters are swapped. memset(_, _, 0) is essentially a noop, and one that could lead to bugs, crashes, or security vulnerabilities.
And to answer my own question, no warnings are generated by this bug:
Because MS has very little incentive to support other drivers. They've got more to lose by possibly convincing other people to give Linux a shot than they do by annoying the few (percentagewise) who use Linux already.
BTW, there's a program called RFStools I think that lets you access Reiser partitions from Windows. I've only tried it once or twice, and I think just to read, but it worked for that. I don't know how complete they are.
(Besides, what are you doing using a filesystem from an alleged murder? )
You take a hash, and sign it with a private key. This is your signature. The loader then takes a hash of the file again. It also decrypts the signature with the public key. Compare the two. If they match, then the file hasn't been tampered with.
Tampering with this requires: 1. Tampering with the loader 2. Tampering with the public key stored in the loader (really part of #1) 3. Breaking MS's private key 4. Producing another executable with the same hash
1 and 2 are possible, but 3 and 4 are computationally hard. (The sun will have turned into a red giant long before the best-known alogrithms have found a solution, even if the hash is the relatively "weak" MD5.)
Not only that, but it shows something about the field of CS which to a large extent is unique, which is that many of the big names are still around and are emailable! I mean, you can't do that in math -- let's see you email Newton and ask him a question. Or ring up Einstein and ask about something in his paper. But just the other day I emailed an author of a paper I read with a question, and he got back in just a couple hours. It's really pretty neat.
And yeah, you can do this with modern stuff in other sciences, but with CS *most* of the field is modern. (There are some notable exceptions of course.)
Maybe you haven't noticed, but Google IS facing trouble, and HAS faced trouble, based upon its caches and book links.
And this is even more blazen in some situations because in the other case the content authors can at least tell Google to not index, via robots.txt. To keep your stuff off YouTube would require constantly monitoring what is up there and reporting it.
Furthermore, Coverity simply cannot accomplish what they claim to accomplish: there is no way of detecting "bugs" automatically--if there were, compilers would already be doing it.
Why do you say that?
I can point you to a number of papers that talk about tools the authors developed that have found a number of bugs in the Linux kernel code base (specifically unchecked user pointer dereferences in the kernel, all exploitable for, say, priviledge escalation, and one of which that had just passed a security audit specifically looking for those bugs), in the SpecInt test suite, in the standard MS-built drivers that come with Windows, that detect whether kernel modules are rootkits or not (at least somewhat; I don't know how much trust I put into that paper), etc.
You're right that you can't have a tool that detects all bugs. But at the same time, there's a TON that can be done in terms of bug hunting that compilers don't do. To say otherwise just demonstrates that you don't know what you're talking about. Perhaps because compilers haven't picked up the analyses that are done by these tools, perhaps because it doesn't really belong in the compiler, I dunno. Probably the latter, because they can produce a lot of false positives.
(I should make two disclosures. First, the bit about the user/kernel pointer bugs required source modification of the kernel to annotate sources and sinks of user pointers. All-in-all, there were under 300 annotations in the whole kernel. That said, this was done at the time of the 2.4 kernel. By now 2.6 may already have the annotations in place in the vanilla kernel. You still need an external tool -- Linus's Sparse -- to check them. (Sparse also requires annotations of EVERYTHING, unlike CQual, which is the one that only needed the 300. So I don't know if the __user annotations are complete. Probably by now they are. The tools are of the same power though once you get those in.) Second, the tool that found the SpecInt benchmarks isn't a completely static-analysis tool. It does static analysis to find where insert runtime checks to guarantee memory safety, but you'd actually need to run the programs though their paces to discover them. That said, these are benchmarks that have been analyzed to death before they got to them, and the bugs hadn't yet surfaced.)
There's a difference though between "a code change can break the code, despite the surrounding code's quality" and "the surrounding code is very brittle; tread lightly." Stuff like "check preconditions of functions, especially if they are on a module boundary" are important and should be present. It's the idea of failing early. If I pass you bad data, and you fail in an assert, that's good; if I pass you bad data, and you corrupt your internal variants and continue running for a while, that's bad. Functions that can't trust their input and yet don't verify it are brittle.
Code like
int A[SIZE]; memset(&A, 0, SIZE);
is brittle. If the first line is changed to
int* A = malloc(SIZE * sizeof(*A));
the second line breaks. Better is to have
memset(A, 0, SIZE)
. In the first case it does the same thing, and in the second case doesn't break.
BTW, in full disclosure, CCured isn't a static analysis tool per se, and may have required running the programs to find the above bugs. But without the instrumentation CCured they would have gone undetected.
Another paper from UC Santa Barbra and (I think) the Technical Institute of Vienna used static analysis of compiled code (not even source!) to try to determine if a kernel module was malicious. (In this context, "malicious" means that it acts like a rootkit; in other words, if it modifies internal kernel data structures that don't belong to the kernel module itself.) They tested 7 rootkits and the entire driver database that comes with Red Hat. Their tool god a perfect detection rate -- no false positives, no false negatives. (The paper does have some issues -- like how did they pick the rootkits they tested, did they analyze them and then build the tool or the other way around, are there other rootkits they didn't test, how easily would it be to make a kernel module that would pass their test, etc., but it does provide a demonstration of the sort of power that static analysis can give you.)
Somebody please explain to me exactly what kind of software bug can be found by automatic scanning that isn't found by standard debugging and compile-time checks.
A *LOT*. The existance of bugs such as buffer overflows PROVES that the "standard debugging and compile-time checkes" are insufficient.
CCured found bugs in a couple different applications. Three separate programs in the SPECINT benchmark set (compress, ijpeg, and go) had bugs. In SPECINT! Probably one of the most heavily analyzed programs ever -- people have been known to tune their programs to perform particularily well on those benchmarks.
CQual found several unchecked dereferences of user pointers in the Linux kernel (2.4 at the time) and device drivers. Which, btw, could have been used as, say, a priviledge escalation mechanism. One of the drivers had just undergone a security audit specifically looking for user/kernel bugs and passed. Linus's Sparse does the same sort of thing as CQual.
Microsoft's Static Driver Verifier found a race condition that could have led to a bug check in the parallel port driver that had been there for years. (Granted, the set of circumstances required to trigger it are absurdly remote, and require removing the physical port form the computer (perhaps by removing a laptop from a dock) at the same time you're doing something else.)
Fact is that there's a LOT that can be detected statically that programmers get wrong.
Slashdot Mirror
The Blue Pill presentation says that DCDEdit won't be in the final release of Vista.
There's certainly a huge incentive for it to be broken--how many botnets will be set to work on it as soon as Vista is released?
:-p
Barring any revelations about P and NP that would have consequences far more broad than MS's certificate being broken (many FAR, FAR more dire consequences (as essentially all crypto from the last few decades is based on the assumption that P!=NP) than just MS having to decide whether to revoke its certificate), I think you can sleep well. There's an outstanding $30,000 reward for anyone who can factor a given 704-bit number. A year ago a team finished putting 30 processor-years (2.2 gHz Opterons) to breaking a 640-bit number. These signatures are probably 1024 or 2048 bits. This is not an easy problem by any means. You could probably throw today's computers at it for millenia and be little closer to breaking MS's certificate.
And I don't like the possibility that, if MS had a dispute with a hardware vendor, they could threaten to revoke the certificates to the vendor's drivers that were already in the field...
Yeah, this you can lose sleep over.
reverse engineer and slide your code inside the signed driver.
I'm gonna mostly let this go because someone else already pointed out that this is more or less impossible. If you change the binary, then the signature is no longer valid, so you have to change the signature to match. Doing so would take... oh... we'll be (very incredibly) optimistic and say a millenia. (Barring any revelations that P=NP after all.)
You could replace the loader that verifies the signatures, but that would require a reboot into another OS. (Assuming Vista has adequate protections of the loader while it's running.)
is it that hard to put in a real filesystem security
You mean like they had in NT 4?
I'm not sure if you've noticed, but at least the professional version of XP, as well as 2000 (and probably NT 4 and maybe 3.51) support far more finer-grained priviledges on the filesystem than any Unix system I've seen. (Including those that support ACLs.)
and make it so that only the administrator can write to system directories and make the user not run as admin???
You mean like they're doing?
Well, I agree that it is not really honest to use DRM here, they are not totally unrelated. The idea is that the DRM in Vista uses kernel support to ensure the no-copying bit. But if you can load your own kernel-mode device drivers, you can do anything, including defeat the DRM schemes. So the driver signing issue protects against both DRM defeation attempts and security issues.
How well, I don't know. We'll find out...
You can self-sign drivers during testing. I don't know the procedure that you have to go through or what UAC prompts pop up. Some other people in this thread say you can install your own root certificates, so that would at least be one approach. You can also apparently turn off the protection during boot from the F8 menu.
Are you aware of the performance penalty of this hardware VM? How does it compare with, say, VMware Workstation?
VMWare produced a paper comparing their binary translation to hardware VM, and most of the benchmarks had the HW slower -- and we're talking like an order of magnitude slower -- than the binary translation. Even the one benchmark they had with second-generation technology in the Core was several times slower than VMWare.
I could see them making something like this as essentially an advertising thing, but I can't imagine it'd be complete BS. And if it's not, it seems like any virtualization attempt has a huge obstacle to overcome in not making the computer seem slower. Because if mine started to act like a vitual machine in VMWare, I'd certainly notice...
What if it just flat out prevents you from modifying the pagefile in the first place?
There are a couple approaches here, with varying degrees of success.
The first is to just prevent access through the API. Check that the filename you're opening isn't the pagefile. If it is, make it readonly. (Or better still, disallow access entirely. Too many security vulnerabilities sit here; there's a lot more you can do than just get your driver loaded.)
The second is to prevent I/O accesses directly. There essentially has to be a way to read raw blocks through the API, because hard drive recovery programs do that. (EDIT: I'm looking at the Blackhat Blue Pill presentation, and this is what they use to get into the pagefile in the first place.) So block that off for the blocks that are in the pagefile. If you locate the pagefile at a known location, say starting at the beginning of the disk, this is easy and fast. (And can be combined with preventing modification to the loader that checks kernel signatures in the first place.)
Both ways assume that the kernel is pure (so your hard drive driver won't allow access or try to do things malicious itself) and bug-free as far as these checks are concerned.
(Oh, and the paper also says that it's possible to make a blue pill that's undetectable, even offline, and even if you know the code and can look for signatures. I think this is impossible.)
Well, hack the boot loader too, then...
And how are you going to do that if the OS prohibits any I/O activity that go to that (those) disk sector(s)? This is very probably not an impossible task to do well. (Though whether Windows does it is an entirely different story entirely.)
And don't say "boot into another OS" because telling the user to "reboot into another OS and run this" is not exactly a viable infection method. If the OS actively protects against this, you *have* to find an exploitable bug in it, or find a way to get into ring 0 to run I/O code itself.
You know, there's a reason no operating system in common use does this, and it's because it's too slow. Doing a ring change takes some time... even a syscall instruction takes a couple hundred cycles.
I shall quote the C++ standard, because that's what I have.
(ISO 14882:2003, clause 5.4)
The above code prescribes two modifications; one from the ++ and one from the assignment.
Here you would also think that the behavior should be specified completely: i++ has to be evaluated before the array index can be taken which has to be loaded before it can be stored in i, but this isn't necessarily the case.
There are sequence points at function entry and exit, which don't apply here, and at the end of each statement.
I'm pretty sure that my reading is right (if you (regular) Google this expression you'll get a number of hits saying it's undefined, including a couple on the C faq (in particular, 3.3), but I'm not exactly an expert, so if you can cite sources that say more than "well, it should be this way because if you think about it..." I'm open to being proved wrong.
Yep. I agree.
However, I think that the threat model is still SUBSTANTIALLY narrowed by signing the kernel. Note in your point 4 you say that you can do it without Windows's consent: if you're a malware author, what are you going to do? Say "reboot your computer into another OS and then run this"? Most users won't even know what you're talking about!
Assuming (and yes, these are big assumptions) that the kernel takes precautions of not allowing anyone to overwrite the loader, including other pieces of kernel code, then you can't do it from a running system; if you can't do it from a running system, it's for all intents and purposes impossible if your goal is to spread malware.
Now, if you can protect the loader, you can protect the kernel image itself; but the latter presents a much larger target. Layered security. There's no drawback* for a closed OS of checking signatures of the kernel except a slightly longer boot, and it adds an additional layer of security.
(* This is a separate idea from requiring drivers from being signed. You could sign the kernel itself and not require drivers to be signed, and use another mechanism to try to ensure that they aren't malicious.)
Finally, once trusted computing spreads its ugly tentacles, the protection of the loader will be hardware enforced, and then you're gonna have a REAL problem.
You just mount your disk under linux or whatever and replace ci.dll with one that always returns "yeah this file hashes OK". Could probably do it with a hex editor.
So you're a rootkit author... what are you gonna do now? Say "reboot your computer into another operating system so I can install myself"?
It is possible to make corrupting the kernel VERY hard to do from within the system, and the first step is to restrict what runs in ring 0. Cryptographically signing the legitimate kernel code is a good part of the solution if you can follow it up. (And there's a lot you have to follow it up with. But I think you could do it without degrading the usability of the system much.)
I don't think that MS's solution of signing drivers though is necessarily a good one on a few levels, even if you ignore the issue of whether they are trying to exert control for a less-than-altruistic purpose, and I don't particularly trust them to follow up with the other things that need to be done to keep a secure kernel.
memset signature looks like this: memset(void *s, int c, size_t n). The semantics are that it copies the lower byte of c into all of the first n bytes starting at s. This is used to initialize structures (e.g. memset(&s, 0, sizeof(s)) ) and to zero out sensitive buffers after they're used (e.g. memset(password, 0, BUFLEN)).
The problem with the code pointed to is that the last two parameters are swapped. memset(_, _, 0) is essentially a noop, and one that could lead to bugs, crashes, or security vulnerabilities.
And to answer my own question, no warnings are generated by this bug:
Because MS has very little incentive to support other drivers. They've got more to lose by possibly convincing other people to give Linux a shot than they do by annoying the few (percentagewise) who use Linux already.
BTW, there's a program called RFStools I think that lets you access Reiser partitions from Windows. I've only tried it once or twice, and I think just to read, but it worked for that. I don't know how complete they are.
(Besides, what are you doing using a filesystem from an alleged murder? )
But Rootkit.com doesn't exist for that purpose, it exists for security researchers.
As someone who is currently studying detection mechanisms for them, I've got the Rootkits book on my shelf a few feet behind my back.
Or do some of its users make it illegitimate, like, say, Napster?
Cryptographically secure signatures?
You take a hash, and sign it with a private key. This is your signature. The loader then takes a hash of the file again. It also decrypts the signature with the public key. Compare the two. If they match, then the file hasn't been tampered with.
Tampering with this requires:
1. Tampering with the loader
2. Tampering with the public key stored in the loader (really part of #1)
3. Breaking MS's private key
4. Producing another executable with the same hash
1 and 2 are possible, but 3 and 4 are computationally hard. (The sun will have turned into a red giant long before the best-known alogrithms have found a solution, even if the hash is the relatively "weak" MD5.)
What makes Sony's legitimate but the ones from Rootkit.com not?
If anything I would argue that rootkit.com is a more legit distribution mechanism than Sony.
This is a fairly amusing one.
I like the memset search on that page too... scary. People need to run Lint or something. (Will Lint pick up that error?)
Not only that, but it shows something about the field of CS which to a large extent is unique, which is that many of the big names are still around and are emailable! I mean, you can't do that in math -- let's see you email Newton and ask him a question. Or ring up Einstein and ask about something in his paper. But just the other day I emailed an author of a paper I read with a question, and he got back in just a couple hours. It's really pretty neat.
And yeah, you can do this with modern stuff in other sciences, but with CS *most* of the field is modern. (There are some notable exceptions of course.)
Maybe you haven't noticed, but Google IS facing trouble, and HAS faced trouble, based upon its caches and book links.
And this is even more blazen in some situations because in the other case the content authors can at least tell Google to not index, via robots.txt. To keep your stuff off YouTube would require constantly monitoring what is up there and reporting it.
Furthermore, Coverity simply cannot accomplish what they claim to accomplish: there is no way of detecting "bugs" automatically--if there were, compilers would already be doing it.
Why do you say that?
I can point you to a number of papers that talk about tools the authors developed that have found a number of bugs in the Linux kernel code base (specifically unchecked user pointer dereferences in the kernel, all exploitable for, say, priviledge escalation, and one of which that had just passed a security audit specifically looking for those bugs), in the SpecInt test suite, in the standard MS-built drivers that come with Windows, that detect whether kernel modules are rootkits or not (at least somewhat; I don't know how much trust I put into that paper), etc.
You're right that you can't have a tool that detects all bugs. But at the same time, there's a TON that can be done in terms of bug hunting that compilers don't do. To say otherwise just demonstrates that you don't know what you're talking about. Perhaps because compilers haven't picked up the analyses that are done by these tools, perhaps because it doesn't really belong in the compiler, I dunno. Probably the latter, because they can produce a lot of false positives.
(I should make two disclosures. First, the bit about the user/kernel pointer bugs required source modification of the kernel to annotate sources and sinks of user pointers. All-in-all, there were under 300 annotations in the whole kernel. That said, this was done at the time of the 2.4 kernel. By now 2.6 may already have the annotations in place in the vanilla kernel. You still need an external tool -- Linus's Sparse -- to check them. (Sparse also requires annotations of EVERYTHING, unlike CQual, which is the one that only needed the 300. So I don't know if the __user annotations are complete. Probably by now they are. The tools are of the same power though once you get those in.) Second, the tool that found the SpecInt benchmarks isn't a completely static-analysis tool. It does static analysis to find where insert runtime checks to guarantee memory safety, but you'd actually need to run the programs though their paces to discover them. That said, these are benchmarks that have been analyzed to death before they got to them, and the bugs hadn't yet surfaced.)
Code likeis brittle. If the first line is changed to the second line breaks. Better is to have . In the first case it does the same thing, and in the second case doesn't break.
BTW, in full disclosure, CCured isn't a static analysis tool per se, and may have required running the programs to find the above bugs. But without the instrumentation CCured they would have gone undetected.
Another paper from UC Santa Barbra and (I think) the Technical Institute of Vienna used static analysis of compiled code (not even source!) to try to determine if a kernel module was malicious. (In this context, "malicious" means that it acts like a rootkit; in other words, if it modifies internal kernel data structures that don't belong to the kernel module itself.) They tested 7 rootkits and the entire driver database that comes with Red Hat. Their tool god a perfect detection rate -- no false positives, no false negatives. (The paper does have some issues -- like how did they pick the rootkits they tested, did they analyze them and then build the tool or the other way around, are there other rootkits they didn't test, how easily would it be to make a kernel module that would pass their test, etc., but it does provide a demonstration of the sort of power that static analysis can give you.)
Somebody please explain to me exactly what kind of software bug can be found by automatic scanning that isn't found by standard debugging and compile-time checks.
A *LOT*. The existance of bugs such as buffer overflows PROVES that the "standard debugging and compile-time checkes" are insufficient.
CCured found bugs in a couple different applications. Three separate programs in the SPECINT benchmark set (compress, ijpeg, and go) had bugs. In SPECINT! Probably one of the most heavily analyzed programs ever -- people have been known to tune their programs to perform particularily well on those benchmarks.
CQual found several unchecked dereferences of user pointers in the Linux kernel (2.4 at the time) and device drivers. Which, btw, could have been used as, say, a priviledge escalation mechanism. One of the drivers had just undergone a security audit specifically looking for user/kernel bugs and passed. Linus's Sparse does the same sort of thing as CQual.
Microsoft's Static Driver Verifier found a race condition that could have led to a bug check in the parallel port driver that had been there for years. (Granted, the set of circumstances required to trigger it are absurdly remote, and require removing the physical port form the computer (perhaps by removing a laptop from a dock) at the same time you're doing something else.)
Fact is that there's a LOT that can be detected statically that programmers get wrong.
He has. Didn't you see the bit about everything happening in a parallel universe?