I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.
Why is some software more secure than others?
How do you measure software security?
Here's my definition on what is secure software.
Intro
I get really tired of seeing these kinds of comments every time some
widely used software has security holes:
No software is secure. The difference is how quickly they fix
it.
It's good that they were found. Now we have less security
holes.
Popular software gets more security audits which is why they seem
to have more security holes.
While they may be partially true, I think they're also very misleading
and disparages the hard work that some secure software authors have
done.
Simplicity Is Security
The difference between secure and insecure software is really the coding
techniques being used by it's authors. Authors of secure software
do everything they can to prevent accidental mistakes from ever happening.
Authors of insecure software just fixes the accidental mistakes.
There are very few secure software authors.
Auditing insecure software doesn't make it secure. Sendmail is a good
example of this. It's been audited countless times by competent people. The
simplest mistakes were catched easily long time ago, but a few very
difficult to find vulnerabilities were found only recently.
How do secure software authors then avoid the kind of security holes that
are difficult to find? By keeping the code simple. The code doesn't get
secure by polluting it with tons of security checks. It gets secure by
keeping the security checks in as few places as possible.
Auditing secure software is easy. You can just quickly browse through
most of the sources without having to stop and look at it carefully.
Everything just looks clean, simple and correct. vsftpd is a good example
of this.
Sure, it's still possible that secure software has some security holes
occationally. It just happens a lot less often (if ever) and usually the
problems are less critical. For example none of the security holes in
Postfix have lead to arbitrary code execution or being able to read other
peoples mails. Denial of Service attacks are nothing compared to them.
Has anyone tried the new 12" powerbooks yet? I have the old one and it's a bit annoying that it gets quite hot after a while. I don't think the 15" and 17" models were nearly that hot. How about the new 12" one? Should I bother buying it or maybe switch to 15"?
Aren't all banks using them? Pretty effectively makes the keyloggers useless. At least the largest banks in Finland do that before giving access to anything important.
One of the most annoying things with Java programs is that I can't figure out what process to kill if I want to kill an application. Luckily I usually use only one Java program at a time, so "killall java" works well enough. Running multiple apps in one VM would only make it worse without some kind of "Java ps".
And why kill them? Because most of the software gets stuck for some reason once in a while. Maybe not always because of the software itself, but because they're waiting for some network timeout or whatever.
I think one of the largest problems with shared calendars have been that there's no standard for it. CAP seems to address that problem. It's still a draft of course, but I'd assume it won't change at least radically anymore.
Re:Security in General Industry
on
P2P Meets Push
·
· Score: 1
Still, your call - the issues that are found in sprintf are very real for the inexperienced coders out there - but they ARE avoidable when sprintf is used correctly
Sure they are, but there are easier ways to make a hole in a wall than banging your head against it. snprintf() and asprintf()-like functions can be used securely with much less trouble.
I know world is full of insecure software, but I try to avoid them as much as I can. And I'm not running bank services on my own computers, so I don't really have a choice in them.
Re:Security features in a language?
on
P2P Meets Push
·
· Score: 1
Check the return value from EVERY system call, EVERY resource allocation, and EVERY library call. Verify ALL inputs before using them, both for length and for sanity of contents. Before EACH time you write something to any kind of buffer, check that you won't write past the end FIRST. Do all of these things in every function of every module of every application.
Even better: write wrappers to commonly used functions so you don't have to do that all the time. For example checking malloc() failures is useless in nearly all situations. Just write a mymalloc() function which kills the program with error message if it can't allocate the memory.
If you are already used to programming, learning a new language is not that difficult.
That depends on what languages you knew before and what you're going to learn. You can quickly learn a syntax of new language, but it takes time before you know how to use it well.
The general concerns with C/C++ are buffer overruns and other memory stomps. If you use the right libraries it's not an issue in either (go look at vsftpd's string functions for an example of what I'm talking about in C). If you're writing insecure C++ code then it's most likely because you're ignoring significant language features (like the STL). It's not a language issue.
Yes, I fully agree. vsftpd is one of the best examples of how to write secure C. As for Kast.. I briefly checked the sources, it's using a lot of code such as:
is this a patch i should have installed on my various linux servers?
Yes. Everyone should have installed grsecurity long time ago for their servers, which provides this protection and much more. It includes ACLs which requires some work to get working, but you don't have to use them. Non-exec stack+heap and address space randomizations require nothing but upgrading the kernel and possibly disabling them for a few binaries that don't like them. I'd guess grsec will include Ingo's patch with it as alternative in future.
Yes, grsecurity includes equilevant protection to this. It uses PAX kernel patch for this. It has existed for years, and Ingo really should have mentioned that in his announcement, assuming he even knew about it?
Difference is that PAX uses some weird x86 kludges to do this and it causes slight speed difference (max. 10% IIRC), but I think that's a very small penalty for very good protection against buffer overflows. It also reduces the maximum memory available to process by.. was it 1-2GB, but there's not many processes that really need that much. And Ingo's patch seems to limit at least number of executable pages even more so.
Essentially, by the time you've figured out which vhost the client is requesting, you're bound to a specific httpd process which normally runs as www/nobody or whatever you've configured it as. As those users cannot setuid to the RunAsUser, you can't modify the uid/euid at that stage, only root can do that and you don't want root handling that part of the negotiation!
You use multiple processes then. You can pass the socket file descriptor to another process via UNIX sockets. Or you could just keep proxying the connection to another process if you want portability.
For example you could have a few "connection broker" processes which would parse the initial request. That process would figure out who exactly should be handling the request. Once that's done, it sends very simple request to very small master process which runs as root, consisting of wanted url handler (file, directory, whatever). The root running process verifies the handler is valid, and then either returns error or forwards the connection to the actual handler process (either exec + setuid(), or reuse existing process).
Something like a proper trusted base allowing a user (www) to setuid to other users (vhost1, vhost1 etc) but that requires a version of Unix that supports it; dunno if Trusted Solaris, OpenBSD or SELinux supply that functionality or not.
I can't believe how bad the IMAP code is for pretty much all of the IMAP clients. Authors haven't probably even bothered to read the whole RFC and assume way too much how servers behave. I haven't found a single usable IMAP client for X that plays nicely with other IMAP clients modifying the mailbox.
Depends on the program really. If there's one guy who audits all the code that goes into the program and actually cares about security, there's a good chance that the software is and stays secure. Linux is large enough that there's no way for a single person to audit everything, but that's not the same for most non-kernel software. Just look at the software by DJB (Qmail, djbdns), Wietse Vanema (Postfix), Chris Evans (vsftpd) and Solar Designer (popa3d) - all of these are written by people who actually know how to write secure code and care enough to keep their software secure. All of them have had zero security holes and it's likely to stay that way.
Hate to break it to you, but ANY program of medium to large size will never be bug free and exploitless. It's the nature of complicated projects.
One way to make software pretty secure is to enforce the restrictions in operating system level. If you're running in empty chroot jail as nobody user, there's not that much the attacker do. Even better if you've disallowed connect() and listen() using systrace or similiar. Privilege separation is good. Server software really should do that more.
I use exim. I have used exim, qmail and sendmail and I like exim by far the most. It is:
* Stable, appears to be secure, yaddah yaddah yaddah.
Appears how? By already having several security holes? It's coding style doesn't look secure at all. It doesn't have have any privilege separation like Qmail and Postfix has. I'd say it's security is around the same as with sendmail, except less people have audited it.
But just because there is one buffer overflow bug doesn't mean that the whole of sendmail is junk. It got fixed didn't it?
One? I think there's been quite a lot more over the years. But anyway, if a program has even one security hole, it's likely it's programmers haven't been careful enough and there's more to be found. Much of the old software just uses "large enough" buffers which one day just stop being large enough after a few changes..
Well.. Problem with ~0 is that it's pretty much the same as just using -1. In both cases you're comparing signed integer to unsigned integer. ~0U would then be same as (unsigned int)-1 again. Also ~ probably isn't fully portable with signed integer types.
That's so that setuid() can be called later once user has logged in, so it's not running as root all the time. Pretty standard implementation for most servers that require logging in.
I've set my anonymous CVS pserver so that it's running under anoncvs uid which has no write access to any of the files in CVS. Only problem with this was that CVS wants to create lock files, but it could be done by setting +t flag for all directories so they will behave like/tmp. That pretty much prevents this exploit from causing me any harm. That and grsec.
That's completely unportable and relies on undefined behaviour and that printf() doesn't use stack at all. I tried it, it didn't work in my Linux/glibc 2.3.1, it didn't print anything.
Well, I'm getting a bit tired of arguing. Even it the speed didn't matter at all, there's still the point that you can't create easily usable GC with C portably. And I don't feel restricted at all with the data stack. Yes, it's a bit more restrictive when comparing to fully automatic GC, but still much less PITA than having to free() the memory which everyone else are doing.
I don't care about speed that much. Portability is one however which I really do care about and I'd hate to depend on requiring an implementation of GC for some specific platform I intend to use.
Telling GC about all your structures sounds much more difficult and error-prone to me than my simple data stack.
Well, one point was to get more publicity to the superior memory management, which although might have been done for decades, I've never ever seen a single software actually doing it. Publicity can be good for giving more attention to old but less know things. Another point was the buffer API, which is also rarely used.
I'll try to fix the document at least some, but if I had done it like you suggest, I had never got out any kind of version of it. Maybe it'd be better for some people who felt they just wasted their time on this, but there's also those others who actually understood it, even if my explanations weren't that good. I guess that's how I usually try to teach, give people a few ideas and pointers and let them figure out the rest instead of trying to brainwash them with lots of explanations and reasonings why it's so much more better. I know it's not perfect, I know it's not useful for everything, but I do think it would be very useful for a lot of projects.
I haven't said anything about C++. C++ is almost as widely accepted as C and I'm sure people would use IMAP server written with C++. But OCaml? Haskell? Ruby? Much less chance for those. And I said later that it wasn't the real point, just a smaller subpoint while the real one being that I still prefer to use C.
Slashdot Mirror
I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.
Why is some software more secure than others?
How do you measure software security?
Here's my definition on what is secure software.
Intro
I get really tired of seeing these kinds of comments every time some widely used software has security holes:
While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.
Simplicity Is Security
The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.
Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.
How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.
Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.
Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.
(some examples in the web page not included)
Has anyone tried the new 12" powerbooks yet? I have the old one and it's a bit annoying that it gets quite hot after a while. I don't think the 15" and 17" models were nearly that hot. How about the new 12" one? Should I bother buying it or maybe switch to 15"?
Aren't all banks using them? Pretty effectively makes the keyloggers useless. At least the largest banks in Finland do that before giving access to anything important.
And why kill them? Because most of the software gets stuck for some reason once in a while. Maybe not always because of the software itself, but because they're waiting for some network timeout or whatever.
I think one of the largest problems with shared calendars have been that there's no standard for it. CAP seems to address that problem. It's still a draft of course, but I'd assume it won't change at least radically anymore.
Sure they are, but there are easier ways to make a hole in a wall than banging your head against it. snprintf() and asprintf()-like functions can be used securely with much less trouble.
I know world is full of insecure software, but I try to avoid them as much as I can. And I'm not running bank services on my own computers, so I don't really have a choice in them.
Even better: write wrappers to commonly used functions so you don't have to do that all the time. For example checking malloc() failures is useless in nearly all situations. Just write a mymalloc() function which kills the program with error message if it can't allocate the memory.
That depends on what languages you knew before and what you're going to learn. You can quickly learn a syntax of new language, but it takes time before you know how to use it well.
Yes, I fully agree. vsftpd is one of the best examples of how to write secure C. As for Kast .. I briefly checked the sources, it's using a lot of code such as:
foo = new[ strlen(bar) + 100 ]; sprintf(foo, "stuff %s", bar);Which is safe only as long as you're careful. And was the author careful enough? No. I'm not touching this thing until the sprintf()s are gone.
Yes. Everyone should have installed grsecurity long time ago for their servers, which provides this protection and much more. It includes ACLs which requires some work to get working, but you don't have to use them. Non-exec stack+heap and address space randomizations require nothing but upgrading the kernel and possibly disabling them for a few binaries that don't like them. I'd guess grsec will include Ingo's patch with it as alternative in future.
Yes, grsecurity includes equilevant protection to this. It uses PAX kernel patch for this. It has existed for years, and Ingo really should have mentioned that in his announcement, assuming he even knew about it?
Difference is that PAX uses some weird x86 kludges to do this and it causes slight speed difference (max. 10% IIRC), but I think that's a very small penalty for very good protection against buffer overflows. It also reduces the maximum memory available to process by .. was it 1-2GB, but there's not many processes that really need that much. And Ingo's patch seems to limit at least number of executable pages even more so.
No, you write correct HTML/CSS to fix it. If it's still broken, forget it and let the konqueror people fix it.
Want to pay for it? ;) I've thought a few times that this would be interesting to do, but I already have other projects and I don't actually need it.
You use multiple processes then. You can pass the socket file descriptor to another process via UNIX sockets. Or you could just keep proxying the connection to another process if you want portability.
For example you could have a few "connection broker" processes which would parse the initial request. That process would figure out who exactly should be handling the request. Once that's done, it sends very simple request to very small master process which runs as root, consisting of wanted url handler (file, directory, whatever). The root running process verifies the handler is valid, and then either returns error or forwards the connection to the actual handler process (either exec + setuid(), or reuse existing process).
There's at least kchuid which could do that.
Here's something to read for IMAP client authors: IMAP Client Coding HOWTO.
Depends on the program really. If there's one guy who audits all the code that goes into the program and actually cares about security, there's a good chance that the software is and stays secure. Linux is large enough that there's no way for a single person to audit everything, but that's not the same for most non-kernel software. Just look at the software by DJB (Qmail, djbdns), Wietse Vanema (Postfix), Chris Evans (vsftpd) and Solar Designer (popa3d) - all of these are written by people who actually know how to write secure code and care enough to keep their software secure. All of them have had zero security holes and it's likely to stay that way.
One way to make software pretty secure is to enforce the restrictions in operating system level. If you're running in empty chroot jail as nobody user, there's not that much the attacker do. Even better if you've disallowed connect() and listen() using systrace or similiar. Privilege separation is good. Server software really should do that more.
Appears how? By already having several security holes? It's coding style doesn't look secure at all. It doesn't have have any privilege separation like Qmail and Postfix has. I'd say it's security is around the same as with sendmail, except less people have audited it.
One? I think there's been quite a lot more over the years. But anyway, if a program has even one security hole, it's likely it's programmers haven't been careful enough and there's more to be found. Much of the old software just uses "large enough" buffers which one day just stop being large enough after a few changes..
Well .. Problem with ~0 is that it's pretty much the same as just using -1. In both cases you're comparing signed integer to unsigned integer. ~0U would then be same as (unsigned int)-1 again. Also ~ probably isn't fully portable with signed integer types.
Or if (i == (unsigned int)-1)
That's so that setuid() can be called later once user has logged in, so it's not running as root all the time. Pretty standard implementation for most servers that require logging in.
I've set my anonymous CVS pserver so that it's running under anoncvs uid which has no write access to any of the files in CVS. Only problem with this was that CVS wants to create lock files, but it could be done by setting +t flag for all directories so they will behave like /tmp. That pretty much prevents this exploit from causing me any harm. That and grsec.
That's completely unportable and relies on undefined behaviour and that printf() doesn't use stack at all. I tried it, it didn't work in my Linux/glibc 2.3.1, it didn't print anything.
Well, I'm getting a bit tired of arguing. Even it the speed didn't matter at all, there's still the point that you can't create easily usable GC with C portably. And I don't feel restricted at all with the data stack. Yes, it's a bit more restrictive when comparing to fully automatic GC, but still much less PITA than having to free() the memory which everyone else are doing.
I don't care about speed that much. Portability is one however which I really do care about and I'd hate to depend on requiring an implementation of GC for some specific platform I intend to use.
Telling GC about all your structures sounds much more difficult and error-prone to me than my simple data stack.
Well, one point was to get more publicity to the superior memory management, which although might have been done for decades, I've never ever seen a single software actually doing it. Publicity can be good for giving more attention to old but less know things. Another point was the buffer API, which is also rarely used.
I'll try to fix the document at least some, but if I had done it like you suggest, I had never got out any kind of version of it. Maybe it'd be better for some people who felt they just wasted their time on this, but there's also those others who actually understood it, even if my explanations weren't that good. I guess that's how I usually try to teach, give people a few ideas and pointers and let them figure out the rest instead of trying to brainwash them with lots of explanations and reasonings why it's so much more better. I know it's not perfect, I know it's not useful for everything, but I do think it would be very useful for a lot of projects.
I haven't said anything about C++. C++ is almost as widely accepted as C and I'm sure people would use IMAP server written with C++. But OCaml? Haskell? Ruby? Much less chance for those. And I said later that it wasn't the real point, just a smaller subpoint while the real one being that I still prefer to use C.