Yes, indeed. Unfortunately, emacs shares the minibuffer between each frame, so if one user tries to start a search-and-replace, for instance, everything goes to hell. Even in this crippled state, though, I found this pretty useful. (I'm willing to bet that Hydra doesn't have the fancy features that Emacs has, anyway, so maybe they're on equal ground after all!)
Well, I wouldn't take what Nintendo says as legal advice. Note how they are careful to say that "back-up" copies are not "authorized" or "necessary," but don't claim that they are illegal.
In fact, the US Code (17 USC 117 (a) (2)) has specific exemptions for backup copies. Check it out. Backup copies are legal!
I don't think they do in this case, since it obviously has some legit uses (they are developing their own games for it), but the US code has laws against such stuff. If you "with knowledge of the infringing activity, induce, cause, or materially contribute to the infringing conduct of another," then you are guilty of contributory infringement. If in fact they know that most people are buying this in order to play pirate roms, then it's pretty likely that they would be in legal trouble. (That is, if they were based in the US!)
ML family languages like SML, O'Caml and Haskell (the language that the whitespace language's interpreter was written in) already use whitespace as function application, so you can say "f 0" instead of "f(0)". Of course, it's not really an "operator" so much as the syntax of the language, but I think it's a pretty good thing that you can't overload it -- that would lead to some really, really fucked up code!
My point is, there is no "loophole" to be had here. It is the copying that is in question, not the license status of the person who receives the copy. So, if they had controls in place to ensure that only one person had access to the CD at a time, then perhaps they'd be in the clear -- but if the intention is to make a fake corporation with a license pool of all CDs, it obviously won't fly.
The reason that copying CDs is illegal is that they are copyrighted, and copying and transmitting copyrighted works without the author's permission (except in cases of "fair use") is illegal. Though a corporation is certainly welcome to build a CD library and loan out physical CDs to its employees, copying them digitally is just a plain ol' copyright violation.
> I'd like to know where these "unchecked" array accesses are at in that code. I sure don't see any.
Well, both accesses to [u] are unchecked, in the sense that the index is only implicitly in bounds. While presumably 'len' is meant to be the length of that array, that isn't obvious from the code -- so, for instance, changing that invariant elsewhere might break this code. What I would expect to see from really paranoid secure code is a standard way of representing and accessing arrays that makes sure that each access is in bounds. Then it is obvious to see that the code is correct. Without that, it's not.
> You must not be familiar with C.
No, I know C quite well.
> Did you not notice the lack of standard string routines?
So? Standard string routines are no longer the source of our buffer overflows. That was the 1990s. These days -- read bugtraq -- it's typically problems with programmer-written parsing routines. (Because you can just 'grep' a source tree for the unsafe string routines!!). Stuff like integer overflows, double frees, and just plain out-of-bound writes are what we worry about today. The last two sendmail holes are of this sort, so was the recent sshd hole. I see nothing special about the qmail code that would prevent this sort of thing. qmail-smtpd.c, your example, is just the kind of hand-written parser that has been faulty in other daemons.
djb has put together some (apparently) secure servers in C, and that is impressive. But I see nothing about the code itself that makes it clear that they are secure -- I just have to trust his arithmetic and the fact that nobody has found any bugs yet. In a safe language it is much easier to look at the code and know that certain kinds of common exploitable bugs just can't happen!
> Not a big problem. Note that dbg_malloc() can similarly traverse the list before returning, and if the malloc()ed pointer is > already in the list, the scenario you cite just happened.
Maybe I'm misunderstanding your answer, but I don't think this does anything. Here's the simplified version of my scenario:
char * x = malloc(10);/* x is 0x800000, debug list holds 0x800000 */ char * y = x;/* debug list holds same value */ free(x);/* debug list empty, x and y dangling */ char * z = malloc(10);/* malloc reallocates at 0x800000, debug list = 0x800000 */ free(y);
This sequence of mallocs and frees is obviously buggy, but if malloc chooses to reallocate z to be the same space where x lived, then your debugging malloc won't complain. (However, if a different code path or previous allocations make z be allocated somewhere else, then we have a potentially exploitable double free.) I'm not particularly saying that this is a big deal (I don't know how common this kind of bug is) but merely backing up my statement that doing correct safe malloc/free requires more sophisticated memory management. But much more importantly:
>> Of course, a scheme like this will also be a lot slower than garbage collection. > Unlike GC, this can be disabled in release builds.
Right, but the release builds are where you want the protection from security holes. Double-frees that are dangerous are not usually ones that happen every time you run the program (because those will cause it to be crashy all the time, which you notice) but the ones that you can trigger via some error condition. For instance, zlib's exploitable hole was like this -- a debugging malloc would never have caught it, unless their test cases included the particular corrupt input that triggered the double-free. Turning off protection is like turning off bounds checks in strncpy for release -- it is precisely that unexpected long input in your release build that you want to protect against!
Well, keeping a list of memory you've allocated before has the main problem that malloc tends to reuse previously-allocated memory--so you may have a dangling pointer that becomes valid because of another malloc. This code won't catch that during debugging. (But it may be triggerable in the release build!) I don't actually know how common this is, but it is often those insidious corner cases that turn into security holes...
Of course, a scheme like this will also be a lot slower than garbage collection.
> They have no bugs of that nature due to the way they are written. If you read the source, it's easy to see why they are > secure. They don't use static buffers and all network input is checked.
Well, I was interested to see what really secure C code must look like (I have never actually read the source to qmail or djbdns before), so I took you up on your offer. The first file I opened (qmail: cdbmss.c), at random, had this code:
int cdbmss_finish(c) struct cdbmss *c; {
int i;
uint32 len;
uint32 u;
if (!cdbmake_split(&c->cdbm,alloc)) return -1;
for (i = 0;i < 256;++i) {
len = cdbmake_throw(&c->cdbm,c->pos,i);   ; for (u = 0;u < len;++u) {
cdbmake_pack(c->packbuf,c->cdbm.hash[u].h);   ; cdbmake_pack(c->packbuf + 4,c->cdbm.hash[u].p);
if (substdio_put(&c->ss,c->packbuf,8) == -1) return -1;
c->pos += 8;/* XXX: overflow? */
}
}
if (substdio_flush(&c->ss) == -1) return -1;
if (seek_begin(c->fd) == -1) return -1;
return substdio_putflush(&c->ss,c->cdbm.final,sizeof(c->c dbm.final)); }
Not only is this code ripe with pointer arithmetic and unchecked (locally) array bounds access, it even says right in it, "XXX overflow?" -- in other words, the author isn't even sure that what he's doing is correct. If the author's not sure, I don't see how it is "easy" to see that this code is secure.
I was actually pretty surprised by the code (looking at a few files after that, I don't see any different) in qmail. Though I would believe that qmail is written by an expert C hacker who is paranoid about security, I don't think there is anything special about the code other than that that gives it extra security. Do you have any particular insight that I'm missing?
> If a garbage collection is invented that really lives up to the promise, it will be available in C++, all without building a > whole language around something that hasn't really arrives and may never arrive.
I doubt that it will end up in C++. How can you do copying garbage collection in C++? You can't, because you can't tell what's a pointer and what's an integer that just happens to be in pointer range. In fact, you can't even do *correct* garbage collection because of C++'s pointer arithmetic -- you can have a pointer that is some offset from an object you care about, and then have that object collected out from under you.
Garbage collection in C++ has to be conservative and non-copying, which means that if C++ programmers want to use GC, they're going to be stuck with essentially the least GC sophisticated technology around. (And they will *still* have to be "on their toes" to make sure they don't do legal things in the language that happen to confound the GC.)
> btw: as for these buffer overflows, etc. You can write malloc and free such that they watch for this sort of thing. It just > costs a few bytes per allocation and some processing power.
I'd really appreciate an explanation of this, because:
- Buffer overflows of stack-allocated arrays (common and most easily exploited) don't pass through malloc.
- The only way I know to protect out-of-bounds read/writes for malloc'd data is to use virtual memory hardware to protect pages around the memory. This is a huge waste of space (at least 2 pages *per allocation* = ~8kb), requires that you never re-allocate any memory (talk about a memory leak!), can only be exact on one side of the allocation unless it happens to be the size of a page, and isn't even correct since way-out-of-bounds writes can end up in another valid page. This is totally impractical except for debugging.
> I believe scripting languages are harder to debug than C++....
I'm not advocating that security-critical code be written in scripting languages, because those have their own class of easy-to-make security holes. I'm arguing for compiled (not VM), safe languages.
> (1) what is the cost? Is the application consuming 10x the resources such as memory?
Java running in a JIT is a memory hog, but that's not because it's a safe language, it's because it's a VM language. SML is not slow nor a memory hog. I hear natively-compiled Java is also pretty efficient, though I don't use it myself. The cost of safety alone is no more than the checks that C programmers already tell themselves they need to add to their code -- and often less because they are inserted and optimized by the compiler.
> (2) does it really solve the problem? e.g. Java's memory management, you still have memory management problems and bugs which > are for all intents and purposes memory leaks, but you give up the ability to address these problems (unless you use your > own VM).
It solves the security holes, yes. I've seldom personally been in a situation where the GC didn't do the right thing, but in those cases it was possible (easy, even) to code my own memory management. What do you have in mind?
Again, safety is not the same as running in a virtual machine! There are many languages which offer native compilation and safety. It's really too bad that Java is the one with the biggest corporation backing it (well, maybe C# is now), because it gives many people the impression that they need to pay all those costs in order to have its benefits that don't relate to binary portability. Slashdot folks, especially, should shop around a bit more than that!
(1) Your code is still functionally wrong. You free the pointer passed in, then write NULL into where that pointer points? Not to mention that you can't dereference a null pointer. I suppose what you mean is:
void mfree(void ** x) {
free(*x);
*x = 0; }... which would then be called like...
char * s = malloc(100); mfree(&s);
(2) Of course, this still doesn't solve the problem of double frees. Programmers don't typically just go around freeing the same memory twice in the same function -- they accidentally free two *aliases* to the same memory. Just so we're concrete, your code (by which I mean my 'corrected' version) doesn't prevent a double free here:
char * s = malloc(100); char * y = s; mfree(&s); mfree(&y);
Preventing double frees *requires* a more sophisticated memory management scheme, like garbage collection.
Even if you do assign null to the pointer, there may be other copies of that pointer around. (Copies of pointers are made, for instance, when you simply pass them to a function. The original poster's code has that very bug -- though it sets the pointer passed to mfree to 0, the code that called mfree doesn't have its pointer changed.) This is how double-frees happen, and it's NOT rare.
W-R-O-N-G, electrum, and this is exactly the kind of thinking that gets programmers in trouble. One of the biggest problems for writers of pointer-based programs (and indeed, compilers for pointer-based languages!) is aliases, which is when two pointers point to the same location. Setting one of those to zero will not help you with the other. Aliasing is not an easy problem to solve once you commit to a language with pointers; there are whole conferences on alias analysis.
> qmail and djbdns have no security bugs and they are written in C. How do you explain that?
Well, it's true that they have no known buffer overflow-style bugs--brute force can occasionally work. But this is still not a glowing review for C. Where do I get my C web server, browser, ssh server/client, etc. that have no exploitable holes in them?
> The big conflict is that it allows you to dive into those issues if you need to. This freedom must not be allowed, I'm told. > Over. And Over.
Freedom is something good. But C++ does not give you just freedom. The problem with C++ is that it makes it too easy to accidentally, er, exercise this freedom, by doing things like overflowing a buffer (suddenly it matters where your memory is laid out), overflowing integers (suddenly it matters that your computer is 32-bit two's-complement), double-deleting a pointer (suddenly the details of the new/delete implementation matter). But, these kinds of issues *should not matter* to most applications. That's the problem with C++ -- not only does it tempt users to use the low level features because they are so accessible and familiar, but easy to make accidents expose low-level details that both lead to non-portable, buggy code, and worse, exploitable security holes.
> They seem to think their language is doing things for them, so they don't have to worry.
But if their language does in fact do things for them (like make buffer overflows unexploitable, make double frees or integer overflows impossible, etc.), then what's so bad about not worrying about those things? Not having to worry about irrelevant things gives you time to worry about things that do matter.
> At least over confident C/C++ programmers KNOW THEY HAVE TO BE CAREFUL, they just feel up to the task.
Though they know they have to be careful, they still repeat the same mistakes over and over. Right?
I don't really understand how you can claim that that's "far less dangerous" than not worrying about things that are taken care of for you.
First, a safe language does NOT have to be interpreted. You can statically compile most of Java to native code -- you'll still have all of the class checking, but there will be no virtual machine, no JIT overhead, and the result will be fairly lean. Java is far from the best though -- SML (see mlton) and O'Caml both produce fast lean native binaries from safe language source.
Second, the JVM "cracking" is totally irrelevant here. The scenario described in that paper is that you have physical access to the machine *and* the ability to supply the program to run. What that translates into here is a hacker saying, "Hey, can I come over to your house, install this Java irc daemon that I wrote, and then shine a lightbulb on your memory?" What we're ACTUALLY talking about is software written by a programmer who intends to make secure code, and a user who doesn't want to corrupt his memory. (In any case, C or C++ or essentially any other language would be just as vulnerable to security holes in a scenario where memory is randomly corrupted.)
So, what are you talking about?
You can, but it's hard, and why would you want to?
on
Too Cool For Secure Code?
·
· Score: 3, Insightful
How do you prevent against double-frees... Use a garbage collector? Integer overflow... use a package that checks for overflow on each integer op? Bad pointer arithmetic... disallow it? Force the programmer to check error conditions on system calls... use exceptions?
What you're describing, is, in fact, a modern high-level language. Except that if you were to do all this stuff in C, you'd be in such an environment that even the simplest stuff is a pain in the ass... calling special functions or macros to access arrays, etc. Nobody wants to do this, and nobody wants to read code that does -- and that's why nobody does. These high-level safe languages do all this stuff automatically, and transparently, so that you can write clean natural code and it is secure against the most common kinds of holes. Java is an example if you like Object Oriented programming, for my part I like SML.
Of course it's possible to write bug-free C code. But it's really hard when you are at the scale of even a modest network daemon. Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?
> This part intrigued me. It seems like most of the issues are with the libraries (libc in particular), not with the languages. > Forgive my ignorance here (don't do much C) but IIRC there are safe and unsafe ways to copy strings, for example.
Though the libraries are partially at fault (printf is a big one), it's not just strcpy any more. It's easy to grep source code for unsafe library functions and replace them. Buffer overflows these days are usually in programmer-written parsing routines (recent sendmail bug), and other bugs like integer overflow (sshd, sunrpc, etc.) and double-free (zlib) are also manifested independently of the libraries.
He's right, though: a safe language like O'Caml, SML, or Java would make these bugs impossible to make. Writing code in a higher-level language also gives the programmer more time to work on other important things, like the security holes that a compiler can't block automatically! O'Caml and SML (depending on the compiler), for their part, are pretty fast and lean too.
Well, first of all, I am a programming languages/compilers researcher, so actually I do know. Some of these languages (or subsets) have even had their safety proven formally. That aside, from a practical standpoint there are still arguments for why this way is better:
These checks happen to be really easy to do, and pretty damn hard to screw up in the context of a compiler. Basically, at every array access you can insert a check that it is in range. Compilers that optimize away some bounds checks (hoisting them outside loops) are somewhat more subject to bugs, although some technologies like typed assembly language can make this, too, just as hard to screw up. In any case, compiler writers are actually pretty good at catching the corner cases and getting this stuff right. (If you know of any bugs in the bounds checking code of a compiler for a safe language that could reasonably lead to an exploitable hole, I'd love to hear it. I don't. On the other hand, there are hundreds of examples of C code that has such bugs.)
Second, C compilers are also subject to bugs, so using a C compiler doesn't save you from that, anyway.
Finally, the compiler is really just providing an extra layer of security. In these languages you are still quite free to verify that you are doing the right thing -- and indeed you should be. But the compiler backs you up in the cases you miss, unlike C. Given the precedent, I really hope people are not using pure will-power-debugged C code to ensure the safety of human lives! I know that, for instance, BMW uses model-checking (a related technology) to ensure the proper operation of their vehicle software; they do NOT trust their programmers to just figure it out in their heads.
>
Perhaps. For network daemons, the CPU time is usually insignificant compared to other bottlenecks -- the disk and network. Those are the most security critical pieces. Perhaps some serious shops would need to have hand-tuned assembly language daemons, but for most users, 20% more cpu would be insignificant compared to the security gain.
More importantly, writing your code in a high level, safe language where you don't need to agonize over the rote security details (and often get them wrong!) gives you a lot more time to optimize your program in ways that really matter. So, even though the *same program* might be 20% slower, the program that you can write in the *same time* may very well be faster.
In any case, I don't see how anyone can possibly argue that our current approach to preventing buffer overflows is working. We need to try SOMETHING else, clearly, and I think this is a pretty good alternative!
No, but a good bet is to reinstall MD5-verified binaries of netstat and ps, and then look for suspicious processes or network servers. All of the rootkits I've seen work by running a hidden background process, or by modifying the kernel -- and you're replacing the kernel, so that should be ok.
Slashdot Mirror
Yes, indeed. Unfortunately, emacs shares the minibuffer between each frame, so if one user tries to start a search-and-replace, for instance, everything goes to hell. Even in this crippled state, though, I found this pretty useful. (I'm willing to bet that Hydra doesn't have the fancy features that Emacs has, anyway, so maybe they're on equal ground after all!)
Well, I wouldn't take what Nintendo says as legal advice. Note how they are careful to say that "back-up" copies are not "authorized" or "necessary," but don't claim that they are illegal.
In fact, the US Code (17 USC 117 (a) (2)) has specific exemptions for backup copies. Check it out. Backup copies are legal!
http://www4.law.cornell.edu/uscode/17/117.html
I don't think they do in this case, since it obviously has some legit uses (they are developing their own games for it), but the US code has laws against such stuff. If you "with knowledge of the infringing activity, induce, cause, or materially contribute to the infringing conduct of another," then you are guilty of contributory infringement. If in fact they know that most people are buying this in order to play pirate roms, then it's pretty likely that they would be in legal trouble. (That is, if they were based in the US!)
ML family languages like SML, O'Caml and Haskell (the language that the whitespace language's interpreter was written in) already use whitespace as function application, so you can say "f 0" instead of "f(0)". Of course, it's not really an "operator" so much as the syntax of the language, but I think it's a pretty good thing that you can't overload it -- that would lead to some really, really fucked up code!
This is supposed to be April Fools? I suppose I believed it, but Ask Slashdot always gets this kind of uninformed question, doesn't it?
My point is, there is no "loophole" to be had here. It is the copying that is in question, not the license status of the person who receives the copy. So, if they had controls in place to ensure that only one person had access to the CD at a time, then perhaps they'd be in the clear -- but if the intention is to make a fake corporation with a license pool of all CDs, it obviously won't fly.
The reason that copying CDs is illegal is that they are copyrighted, and copying and transmitting copyrighted works without the author's permission (except in cases of "fair use") is illegal. Though a corporation is certainly welcome to build a CD library and loan out physical CDs to its employees, copying them digitally is just a plain ol' copyright violation.
> I'd like to know where these "unchecked" array accesses are at in that code. I sure don't see any.
Well, both accesses to [u] are unchecked, in the sense that the index is only implicitly in bounds. While presumably 'len' is meant to be the length of that array, that isn't obvious from the code -- so, for instance, changing that invariant elsewhere might break this code. What I would expect to see from really paranoid secure code is a standard way of representing and accessing arrays that makes sure that each access is in bounds. Then it is obvious to see that the code is correct. Without that, it's not.
> You must not be familiar with C.
No, I know C quite well.
> Did you not notice the lack of standard string routines?
So? Standard string routines are no longer the source of our buffer overflows. That was the 1990s. These days -- read bugtraq -- it's typically problems with programmer-written parsing routines. (Because you can just 'grep' a source tree for the unsafe string routines!!). Stuff like integer overflows, double frees, and just plain out-of-bound writes are what we worry about today. The last two sendmail holes are of this sort, so was the recent sshd hole. I see nothing special about the qmail code that would prevent this sort of thing. qmail-smtpd.c, your example, is just the kind of hand-written parser that has been faulty in other daemons.
djb has put together some (apparently) secure servers in C, and that is impressive. But I see nothing about the code itself that makes it clear that they are secure -- I just have to trust his arithmetic and the fact that nobody has found any bugs yet. In a safe language it is much easier to look at the code and know that certain kinds of common exploitable bugs just can't happen!
> Not a big problem. Note that dbg_malloc() can similarly traverse the list before returning, and if the malloc()ed pointer is
/* x is 0x800000, debug list holds 0x800000 */ /* debug list holds same value */ /* debug list empty, x and y dangling */ /* malloc reallocates at 0x800000, debug list = 0x800000 */
> already in the list, the scenario you cite just happened.
Maybe I'm misunderstanding your answer, but I don't think this does anything. Here's the simplified version of my scenario:
char * x = malloc(10);
char * y = x;
free(x);
char * z = malloc(10);
free(y);
This sequence of mallocs and frees is obviously buggy, but if malloc chooses to reallocate z to be the same space where x lived, then your debugging malloc won't complain. (However, if a different code path or previous allocations make z be allocated somewhere else, then we have a potentially exploitable double free.) I'm not particularly saying that this is a big deal (I don't know how common this kind of bug is) but merely backing up my statement that doing correct safe malloc/free requires more sophisticated memory management. But much more importantly:
>> Of course, a scheme like this will also be a lot slower than garbage collection.
> Unlike GC, this can be disabled in release builds.
Right, but the release builds are where you want the protection from security holes. Double-frees that are dangerous are not usually ones that happen every time you run the program (because those will cause it to be crashy all the time, which you notice) but the ones that you can trigger via some error condition. For instance, zlib's exploitable hole was like this -- a debugging malloc would never have caught it, unless their test cases included the particular corrupt input that triggered the double-free. Turning off protection is like turning off bounds checks in strncpy for release -- it is precisely that unexpected long input in your release build that you want to protect against!
Well, keeping a list of memory you've allocated before has the main problem that malloc tends to reuse previously-allocated memory--so you may have a dangling pointer that becomes valid because of another malloc. This code won't catch that during debugging. (But it may be triggerable in the release build!) I don't actually know how common this is, but it is often those insidious corner cases that turn into security holes...
Of course, a scheme like this will also be a lot slower than garbage collection.
> secure. They don't use static buffers and all network input is checked.
Well, I was interested to see what really secure C code must look like (I have never actually read the source to qmail or djbdns before), so I took you up on your offer. The first file I opened (qmail: cdbmss.c), at random, had this code:Not only is this code ripe with pointer arithmetic and unchecked (locally) array bounds access, it even says right in it, "XXX overflow?" -- in other words, the author isn't even sure that what he's doing is correct. If the author's not sure, I don't see how it is "easy" to see that this code is secure.
I was actually pretty surprised by the code (looking at a few files after that, I don't see any different) in qmail. Though I would believe that qmail is written by an expert C hacker who is paranoid about security, I don't think there is anything special about the code other than that that gives it extra security. Do you have any particular insight that I'm missing?
> If a garbage collection is invented that really lives up to the promise, it will be available in C++, all without building a
....
> whole language around something that hasn't really arrives and may never arrive.
I doubt that it will end up in C++. How can you do copying garbage collection in C++? You can't, because you can't tell what's a pointer and what's an integer that just happens to be in pointer range. In fact, you can't even do *correct* garbage collection because of C++'s pointer arithmetic -- you can have a pointer that is some offset from an object you care about, and then have that object collected out from under you.
Garbage collection in C++ has to be conservative and non-copying, which means that if C++ programmers want to use GC, they're going to be stuck with essentially the least GC sophisticated technology around. (And they will *still* have to be "on their toes" to make sure they don't do legal things in the language that happen to confound the GC.)
> btw: as for these buffer overflows, etc. You can write malloc and free such that they watch for this sort of thing. It just
> costs a few bytes per allocation and some processing power.
I'd really appreciate an explanation of this, because:
- Buffer overflows of stack-allocated arrays (common and most easily exploited) don't pass through malloc.
- The only way I know to protect out-of-bounds read/writes for malloc'd data is to use virtual memory hardware to protect pages around the memory. This is a huge waste of space (at least 2 pages *per allocation* = ~8kb), requires that you never re-allocate any memory (talk about a memory leak!), can only be exact on one side of the allocation unless it happens to be the size of a page, and isn't even correct since way-out-of-bounds writes can end up in another valid page. This is totally impractical except for debugging.
> I believe scripting languages are harder to debug than C++
I'm not advocating that security-critical code be written in scripting languages, because those have their own class of easy-to-make security holes. I'm arguing for compiled (not VM), safe languages.
> (1) what is the cost? Is the application consuming 10x the resources such as memory?
Java running in a JIT is a memory hog, but that's not because it's a safe language, it's because it's a VM language. SML is not slow nor a memory hog. I hear natively-compiled Java is also pretty efficient, though I don't use it myself. The cost of safety alone is no more than the checks that C programmers already tell themselves they need to add to their code -- and often less because they are inserted and optimized by the compiler.
> (2) does it really solve the problem? e.g. Java's memory management, you still have memory management problems and bugs which
> are for all intents and purposes memory leaks, but you give up the ability to address these problems (unless you use your
> own VM).
It solves the security holes, yes. I've seldom personally been in a situation where the GC didn't do the right thing, but in those cases it was possible (easy, even) to code my own memory management. What do you have in mind?
Again, safety is not the same as running in a virtual machine! There are many languages which offer native compilation and safety. It's really too bad that Java is the one with the biggest corporation backing it (well, maybe C# is now), because it gives many people the impression that they need to pay all those costs in order to have its benefits that don't relate to binary portability. Slashdot folks, especially, should shop around a bit more than that!
Mr. AC,
... which would then be called like ...
Still, if you want to be a pissent little holier than though Slashdot poster, then go right ahead.
extern __inline__ void mfree(void *x){
if(x!=NULL){
free(x);
(unsigned long)*x=NULL;
}
}
Are you still kidding?
(1) Your code is still functionally wrong. You free the pointer passed in, then write NULL into where that pointer points? Not to mention that you can't dereference a null pointer. I suppose what you mean is:
void mfree(void ** x) {
free(*x);
*x = 0;
}
char * s = malloc(100);
mfree(&s);
(2) Of course, this still doesn't solve the problem of double frees. Programmers don't typically just go around freeing the same memory twice in the same function -- they accidentally free two *aliases* to the same memory. Just so we're concrete, your code (by which I mean my 'corrected' version) doesn't prevent a double free here:
char * s = malloc(100);
char * y = s;
mfree(&s);
mfree(&y);
Preventing double frees *requires* a more sophisticated memory management scheme, like garbage collection.
Even if you do assign null to the pointer, there may be other copies of that pointer around. (Copies of pointers are made, for instance, when you simply pass them to a function. The original poster's code has that very bug -- though it sets the pointer passed to mfree to 0, the code that called mfree doesn't have its pointer changed.) This is how double-frees happen, and it's NOT rare.
W-R-O-N-G, electrum, and this is exactly the kind of thinking that gets programmers in trouble. One of the biggest problems for writers of pointer-based programs (and indeed, compilers for pointer-based languages!) is aliases, which is when two pointers point to the same location. Setting one of those to zero will not help you with the other. Aliasing is not an easy problem to solve once you commit to a language with pointers; there are whole conferences on alias analysis.
> qmail and djbdns have no security bugs and they are written in C. How do you explain that?
Well, it's true that they have no known buffer overflow-style bugs--brute force can occasionally work. But this is still not a glowing review for C. Where do I get my C web server, browser, ssh server/client, etc. that have no exploitable holes in them?
> The big conflict is that it allows you to dive into those issues if you need to. This freedom must not be allowed, I'm told.
> Over. And Over.
Freedom is something good. But C++ does not give you just freedom. The problem with C++ is that it makes it too easy to accidentally, er, exercise this freedom, by doing things like overflowing a buffer (suddenly it matters where your memory is laid out), overflowing integers (suddenly it matters that your computer is 32-bit two's-complement), double-deleting a pointer (suddenly the details of the new/delete implementation matter). But, these kinds of issues *should not matter* to most applications. That's the problem with C++ -- not only does it tempt users to use the low level features because they are so accessible and familiar, but easy to make accidents expose low-level details that both lead to non-portable, buggy code, and worse, exploitable security holes.
> They seem to think their language is doing things for them, so they don't have to worry.
But if their language does in fact do things for them (like make buffer overflows unexploitable, make double frees or integer overflows impossible, etc.), then what's so bad about not worrying about those things? Not having to worry about irrelevant things gives you time to worry about things that do matter.
> At least over confident C/C++ programmers KNOW THEY HAVE TO BE CAREFUL, they just feel up to the task.
Though they know they have to be careful, they still repeat the same mistakes over and over. Right?
I don't really understand how you can claim that that's "far less dangerous" than not worrying about things that are taken care of for you.
OK, chewie, what the hell does that mean?
First, a safe language does NOT have to be interpreted. You can statically compile most of Java to native code -- you'll still have all of the class checking, but there will be no virtual machine, no JIT overhead, and the result will be fairly lean. Java is far from the best though -- SML (see mlton) and O'Caml both produce fast lean native binaries from safe language source.
Second, the JVM "cracking" is totally irrelevant here. The scenario described in that paper is that you have physical access to the machine *and* the ability to supply the program to run. What that translates into here is a hacker saying, "Hey, can I come over to your house, install this Java irc daemon that I wrote, and then shine a lightbulb on your memory?" What we're ACTUALLY talking about is software written by a programmer who intends to make secure code, and a user who doesn't want to corrupt his memory. (In any case, C or C++ or essentially any other language would be just as vulnerable to security holes in a scenario where memory is randomly corrupted.)
So, what are you talking about?
How do you prevent against double-frees ... Use a garbage collector? Integer overflow ... use a package that checks for overflow on each integer op? Bad pointer arithmetic ... disallow it? Force the programmer to check error conditions on system calls ... use exceptions?
What you're describing, is, in fact, a modern high-level language. Except that if you were to do all this stuff in C, you'd be in such an environment that even the simplest stuff is a pain in the ass... calling special functions or macros to access arrays, etc. Nobody wants to do this, and nobody wants to read code that does -- and that's why nobody does. These high-level safe languages do all this stuff automatically, and transparently, so that you can write clean natural code and it is secure against the most common kinds of holes. Java is an example if you like Object Oriented programming, for my part I like SML.
Of course it's possible to write bug-free C code. But it's really hard when you are at the scale of even a modest network daemon. Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?
> This part intrigued me. It seems like most of the issues are with the libraries (libc in particular), not with the languages.
> Forgive my ignorance here (don't do much C) but IIRC there are safe and unsafe ways to copy strings, for example.
Though the libraries are partially at fault (printf is a big one), it's not just strcpy any more. It's easy to grep source code for unsafe library functions and replace them. Buffer overflows these days are usually in programmer-written parsing routines (recent sendmail bug), and other bugs like integer overflow (sshd, sunrpc, etc.) and double-free (zlib) are also manifested independently of the libraries.
He's right, though: a safe language like O'Caml, SML, or Java would make these bugs impossible to make. Writing code in a higher-level language also gives the programmer more time to work on other important things, like the security holes that a compiler can't block automatically! O'Caml and SML (depending on the compiler), for their part, are pretty fast and lean too.
1 isn't prime.
An AC flames,
>
Well, first of all, I am a programming languages/compilers researcher, so actually I do know. Some of these languages (or subsets) have even had their safety proven formally. That aside, from a practical standpoint there are still arguments for why this way is better:
These checks happen to be really easy to do, and pretty damn hard to screw up in the context of a compiler. Basically, at every array access you can insert a check that it is in range. Compilers that optimize away some bounds checks (hoisting them outside loops) are somewhat more subject to bugs, although some technologies like typed assembly language can make this, too, just as hard to screw up. In any case, compiler writers are actually pretty good at catching the corner cases and getting this stuff right. (If you know of any bugs in the bounds checking code of a compiler for a safe language that could reasonably lead to an exploitable hole, I'd love to hear it. I don't. On the other hand, there are hundreds of examples of C code that has such bugs.)
Second, C compilers are also subject to bugs, so using a C compiler doesn't save you from that, anyway.
Finally, the compiler is really just providing an extra layer of security. In these languages you are still quite free to verify that you are doing the right thing -- and indeed you should be. But the compiler backs you up in the cases you miss, unlike C. Given the precedent, I really hope people are not using pure will-power-debugged C code to ensure the safety of human lives! I know that, for instance, BMW uses model-checking (a related technology) to ensure the proper operation of their vehicle software; they do NOT trust their programmers to just figure it out in their heads.
>
Perhaps. For network daemons, the CPU time is usually insignificant compared to other bottlenecks -- the disk and network. Those are the most security critical pieces. Perhaps some serious shops would need to have hand-tuned assembly language daemons, but for most users, 20% more cpu would be insignificant compared to the security gain.
More importantly, writing your code in a high level, safe language where you don't need to agonize over the rote security details (and often get them wrong!) gives you a lot more time to optimize your program in ways that really matter. So, even though the *same program* might be 20% slower, the program that you can write in the *same time* may very well be faster.
In any case, I don't see how anyone can possibly argue that our current approach to preventing buffer overflows is working. We need to try SOMETHING else, clearly, and I think this is a pretty good alternative!
No, but a good bet is to reinstall MD5-verified binaries of netstat and ps, and then look for suspicious processes or network servers. All of the rootkits I've seen work by running a hidden background process, or by modifying the kernel -- and you're replacing the kernel, so that should be ok.