Is there any document out there which explains why/dev/dsp doesn't get mixing with ALSA? And why nobody tried to patch that yet?
Yeah, TFA explains it.. Here's it in short:/dev/dsp goes to kernelspace, while ALSA does mixing in userspace. I've no idea how difficult it would be to make ALSA do sound mixing in kernelspace.
http://underhanded.xcott.com/ doesn't mention anything about last year's winners and the contest ended almost 5 months ago.. The one time I bother sending a submission to these kind of contests and the contest appears to die:(
I visited Directi a couple of months ago when they wanted to see me and begin sponsoring my open source IMAP server. The company certainly didn't feel like a sleazy spam harboring company, so I find these accusations a bit hard to belive. The summary could have also made it a lot clearer that Directi is saying these are all lies instead of just a small "BTW here's their reply" link.
I hate it that OpenOffice is so often associated as "one of the best open source software" among with Linux and Firefox. Every time I've tried OOo (on Linux) I've immediately hated it. It's slow, bloated and annoying to use. Disabling its annoying "helpful" features takes a lot of time. So a while ago I bought MS Office 2008 for Mac, in part just so that I can say I would rather buy MS Office than use OOo for free.
(And no, I won't try to help them make it better just because it's open source. I'm busy enough as it is with my own open source projects.)
Who cares if it is LIBNAME_VALUE or LIBNAME_ENUM.VALUE?
Enums are visible to gdb, macros aren't (at least by default, not sure if there's some option). Also named enums make it possible for compiler to do type checking to make sure you're not mixing enums into wrong variables accidentally. Unfortunately gcc doesn't give warnings about those.
Your post made me test OpenOffice.org 2.2.1 in Debian. With only a couple of minutes of testing, I found the following problems:
I use alt-mouseclick to raise/move windows. After doing this to OOo the
focus moves to File menu. No other software has this problem.
Word completion feature is still enabled by default. It's the most
annoying feature I've ever seen in a software. Seeing words suddenly pop up
on screen completely distracts you from whatever you were thinking about
writing. And why does it have to have its own setup dialog? I was expecting
to find it from Options, but oh no. At least this time I found the AutoCorrect menu, last time I gave up and just wrote the document with a text editor and copy&pasted to OOo to add the formatting.
Autosaving causes the window to flicker, Ctrl-S doesn't. Why? At least there's no more "This document has changed, do you want to save it?" questions. Oh how I hated that dialog when trying to read a document that I had accidentally changed a bit.
Inserting a table left parts of the table insertion dialog visible to
screen, requiring a window resize to refresh it out.
Whenever a Table mini-window is created (e.g. clicking a cell, or more annoyingly moving a cursor into a cell) the focus is lost.
Using 60MB of memory (RSS) to display an empty document and 80MB to display a 9 page document seems pretty bloaty.
So I guess it's better than last time I tried, but losing focus all the time would make me curse it if I really had to use it.
There's nothing in labels that breaks IMAP specifications. In fact by the end of this summer Dovecot will most likely support GMail-style virtual mailboxes created by a specific keyword (IMAP term for labels) search. And whatever other searches the user wants to use for virtual mailboxes.
Sorry, but I don't agree. I think if you rely on user input validation you're going to have more security holes in your program than if you built it from the assumption that every single string in your code may contain whatever data. It's much easier to figure out where the few problematic areas are (typically only printing and SQL queries, maybe also writing to logs) and just make sure that those are done securely no matter what their input is. If your security comes only from validating the user input, the input may be modified in insecure ways within your application that's not so easily detectable.
Of course once you know your program is already safe against any kind of user input, you may add input validation. But that's not to prevent security holes, only to give user (and admin) meaningful error messages and possibly guard against DoS attacks with eg. too large user inputs. I suppose input validation in your program may also help if the same input is transferred into other people's buggy programs, but that's not really your program's fault anymore..
Sure that works if all you do with the string is print it out. Now what if you also want to store it into a SQL database, as is usually done? You'll have to unescape it before inserting it, or alternatively both waste more space in the database and remember to have to NOT escape data that comes from the SQL database so it won't get escaped twice (< shown as <). And if you're not escaping data that comes from SQL database you better make sure that ALL the data that is stored in there is escaped. And never mind the other problems that you might have when manipulating the escaped input before printing or storing it..
Or perhaps it's easier not to worry about the escaping problems at all that might come, and just always print data like: html_printf("Hello, %s", $_REQUEST["user"]); You can even verify that all prints are safe using a grep command that checks that no "print" commands exist and no variables are used as html_printf()'s first parameter.
The end result was that I had to make a user click on a link that first took the victim to my server
I think this is the reason why people aren't that concerned about XSS. This requires that the attacker knows someone who has access to the web site and a way to get him to click on the link. I would certainly never click on a suspicious looking link. But sure, not everyone does that and if there are other post-login holes to get yourself into an admin, that's a problem for you too.
One thing that annoys me when discussing XSS problems and such is that people always just suggest to validate input. I've built perfectly secure PHP applications that don't validate input at all, they just don't print the output using "print" but another function that properly escapes the output. So much more easier that way than having to think about input validation for every single new field you add.
You still talked only about server side. That's obvious to me that passwords shouldn't be stored in plaintext there. But in the client side the client needs to know the plaintext password (or equilevant secret) to be able to send it to server, and if user wants the password to be remembered, there aren't really any better choices to store it to disk than base64-coded, unless the operating system itself supports something special (such as OSX's keychain).
No more "base 64 encoded password in a text file" stuff please!
So how should it be done, assuming the user wants passwords to be remembered? No matter how you store it, it's no more secure than base64 encoding since you'll have to be able to open it anyway. Unless you're talking about something completely different.
Every single popular software author should make sure they PGP sign their packages AND verify it automatically at least once a day. I've began doing this for my projects since irssi was backdoored a few years ago. A few different computers download and check the signature of the latest release every single day, and email me if anything went wrong.
Even better would be if GNU tar supported such signatures automatically. For example if file extension was "tar.pgp", it could force checking the signature, and if it wasn't found or it was invalid, it wouldn't do anything. That way I wouldn't ever have to think about verifying it - I could see from the file name that it should be valid (of course, getting the trusted pgp keys might require more work..). Oh, and of course the.tar.pgp would be backwards compatible with standard tar, they would just contain some extra "checksum.pgp" file or something.
..but which has had several code audits. Or if not, make your own. That is if you care about keeping your system as secure as possible and not just keep patching after patching.
That's how I do it - I try to audit all possibly security critical software before beginning to use them. If it looks bad, I go look for another one. And if I can't make sure something is secure, I try to at least make it as safe as possible to use. For example if you crack into my anonymous CVS pserver, you're still not able to modify any of the existing files.
Having your email delayed by a brief polling interval is surely less important than eliminating polling overhead on the server.
Nothing prevents the server from internally using the exact same technique for handling polling commands as when client is issuing IDLE command. The overhead for polling is then just a few more bytes of network traffic per polling period (over a minute usually).
Hmm. I wonder if that's really a good idea to implement, my server currently just requires two stat() calls per NOOP command if nothing has changed so it's not exactly slow either.
This is where input validation comes in. Check every input value for sanity.
IMHO this is completely wrong way to do it. Write your code so that you don't have to check input for sanity - your code should be secure no matter what the input is. What input validation is useful is giving user meaningful error messages.
Writing bulletproof software is TEDIOUS. You still have to verify everything, and still somebody's going to find the one thing you missed and exploit the hell out of it...
Yes, like you say here. You're going to miss something if you rely on input validation to catch the security holes.
Two months ago I found the problem and gave a patch to fix it. Looks like the bad guys were smarter than I thought and figured out a way to exploit it. Lesson: release fixes for even potential security holes immediately:)
Oh and I'd also like to point out that Dovecot executes SSL code in nobody-chrooted environment where security holes in OpenSSL shouldn't cause much trouble, assuming OS's kernel doesn't have security holes to escape the chroot jail. If I don't trust something, I'll try make sure it doesn't have to be trusted:)
I always wanted to have better support for error handling in C. Programmers should not be forced to handle errors by nested if's, "goto error" and wrapper functions that do nothing but check the result of another function and do cleanup.
Exceptions would be nice, but I think in most cases the cleanup is just freeing dynamically allocated memory. Solution is to get rid of the free() calls. Garbage collector, memory pools, alloca(), data stack, etc. Data stack and memory pools have worked very well with my latest project. Error handling is almost always just a return call and there's hardly any wrapper functions just for handling errors. Too bad I haven't yet had time to test how well they'd work in other kind of software. I'd guess pretty well except maybe for general purpose libraries since they require a bit different way of writing C code.
I think I'll have to change the wording some more. Complex things require complex code, that's fine. If there's a security hole because the behaviour was wrong in some case, it's understandable.
What I especially don't like is that the same old buffer overflow and other memory allocation related problems come up over and over again. The 1. problem in this case was a double-free() bug. Although this is the most difficult C-related problem to solve easily (without garbage collector), with cleaner code it likely wouldn't have gone there in the first place. If you can easily see where the memory is allocated and deallocated, it's hard to screw up.
Complexity is fine, but it doesn't mean that the implementation has to be full of code that is both difficult to follow and that looks insecure at the first glance. I have looked at both GNUTLS and OpenSSL sources and GNUTLS is significantly easier to follow and it does pretty much the same thing.
Auditing depends on what you're interested in. Auditing sources for buffer overflows and other common security flaws must be easy. Auditing for crashes and more subtle bugs of course requires to be much more careful.
Slashdot Mirror
Is there any document out there which explains why /dev/dsp doesn't get mixing with ALSA? And why nobody tried to patch that yet?
Yeah, TFA explains it.. Here's it in short: /dev/dsp goes to kernelspace, while ALSA does mixing in userspace. I've no idea how difficult it would be to make ALSA do sound mixing in kernelspace.
http://underhanded.xcott.com/ doesn't mention anything about last year's winners and the contest ended almost 5 months ago.. The one time I bother sending a submission to these kind of contests and the contest appears to die :(
I just tested Zarafa's IMAP support and it has major issues. In fact it ranks as the worst IMAP server I've tested so far.
I visited Directi a couple of months ago when they wanted to see me and begin sponsoring my open source IMAP server. The company certainly didn't feel like a sleazy spam harboring company, so I find these accusations a bit hard to belive. The summary could have also made it a lot clearer that Directi is saying these are all lies instead of just a small "BTW here's their reply" link.
I hate it that OpenOffice is so often associated as "one of the best open source software" among with Linux and Firefox. Every time I've tried OOo (on Linux) I've immediately hated it. It's slow, bloated and annoying to use. Disabling its annoying "helpful" features takes a lot of time. So a while ago I bought MS Office 2008 for Mac, in part just so that I can say I would rather buy MS Office than use OOo for free.
(And no, I won't try to help them make it better just because it's open source. I'm busy enough as it is with my own open source projects.)
Enums are visible to gdb, macros aren't (at least by default, not sure if there's some option). Also named enums make it possible for compiler to do type checking to make sure you're not mixing enums into wrong variables accidentally. Unfortunately gcc doesn't give warnings about those.
- I use alt-mouseclick to raise/move windows. After doing this to OOo the
focus moves to File menu. No other software has this problem.
- Word completion feature is still enabled by default. It's the most
annoying feature I've ever seen in a software. Seeing words suddenly pop up
on screen completely distracts you from whatever you were thinking about
writing. And why does it have to have its own setup dialog? I was expecting
to find it from Options, but oh no. At least this time I found the AutoCorrect menu, last time I gave up and just wrote the document with a text editor and copy&pasted to OOo to add the formatting.
- Autosaving causes the window to flicker, Ctrl-S doesn't. Why? At least there's no more "This document has changed, do you want to save it?" questions. Oh how I hated that dialog when trying to read a document that I had accidentally changed a bit.
- Inserting a table left parts of the table insertion dialog visible to
screen, requiring a window resize to refresh it out.
- Whenever a Table mini-window is created (e.g. clicking a cell, or more annoyingly moving a cursor into a cell) the focus is lost.
- Using 60MB of memory (RSS) to display an empty document and 80MB to display a 9 page document seems pretty bloaty.
So I guess it's better than last time I tried, but losing focus all the time would make me curse it if I really had to use it.There's nothing in labels that breaks IMAP specifications. In fact by the end of this summer Dovecot will most likely support GMail-style virtual mailboxes created by a specific keyword (IMAP term for labels) search. And whatever other searches the user wants to use for virtual mailboxes.
Sorry, but I don't agree. I think if you rely on user input validation you're going to have more security holes in your program than if you built it from the assumption that every single string in your code may contain whatever data. It's much easier to figure out where the few problematic areas are (typically only printing and SQL queries, maybe also writing to logs) and just make sure that those are done securely no matter what their input is. If your security comes only from validating the user input, the input may be modified in insecure ways within your application that's not so easily detectable.
Of course once you know your program is already safe against any kind of user input, you may add input validation. But that's not to prevent security holes, only to give user (and admin) meaningful error messages and possibly guard against DoS attacks with eg. too large user inputs. I suppose input validation in your program may also help if the same input is transferred into other people's buggy programs, but that's not really your program's fault anymore..
Sure that works if all you do with the string is print it out. Now what if you also want to store it into a SQL database, as is usually done? You'll have to unescape it before inserting it, or alternatively both waste more space in the database and remember to have to NOT escape data that comes from the SQL database so it won't get escaped twice (< shown as <). And if you're not escaping data that comes from SQL database you better make sure that ALL the data that is stored in there is escaped. And never mind the other problems that you might have when manipulating the escaped input before printing or storing it..
Or perhaps it's easier not to worry about the escaping problems at all that might come, and just always print data like: html_printf("Hello, %s", $_REQUEST["user"]); You can even verify that all prints are safe using a grep command that checks that no "print" commands exist and no variables are used as html_printf()'s first parameter.
I think this is the reason why people aren't that concerned about XSS. This requires that the attacker knows someone who has access to the web site and a way to get him to click on the link. I would certainly never click on a suspicious looking link. But sure, not everyone does that and if there are other post-login holes to get yourself into an admin, that's a problem for you too.
One thing that annoys me when discussing XSS problems and such is that people always just suggest to validate input. I've built perfectly secure PHP applications that don't validate input at all, they just don't print the output using "print" but another function that properly escapes the output. So much more easier that way than having to think about input validation for every single new field you add.
You still talked only about server side. That's obvious to me that passwords shouldn't be stored in plaintext there. But in the client side the client needs to know the plaintext password (or equilevant secret) to be able to send it to server, and if user wants the password to be remembered, there aren't really any better choices to store it to disk than base64-coded, unless the operating system itself supports something special (such as OSX's keychain).
Oh, from server's point of view, not from a client's point of view which actually needs to know the password to be able to send it.
So how should it be done, assuming the user wants passwords to be remembered? No matter how you store it, it's no more secure than base64 encoding since you'll have to be able to open it anyway. Unless you're talking about something completely different.
Even better would be if GNU tar supported such signatures automatically. For example if file extension was "tar.pgp", it could force checking the signature, and if it wasn't found or it was invalid, it wouldn't do anything. That way I wouldn't ever have to think about verifying it - I could see from the file name that it should be valid (of course, getting the trusted pgp keys might require more work..). Oh, and of course the .tar.pgp would be backwards compatible with standard tar, they would just contain some extra "checksum.pgp" file or something.
Gaim's security doesn't look very good either. Switch if you like, but don't expect it to be any more secure.
That's how I do it - I try to audit all possibly security critical software before beginning to use them. If it looks bad, I go look for another one. And if I can't make sure something is secure, I try to at least make it as safe as possible to use. For example if you crack into my anonymous CVS pserver, you're still not able to modify any of the existing files.
And here's some more old ranting..
Hmm. I wonder if that's really a good idea to implement, my server currently just requires two stat() calls per NOOP command if nothing has changed so it's not exactly slow either.
More ranting about the subject..
Two months ago I found the problem and gave a patch to fix it. Looks like the bad guys were smarter than I thought and figured out a way to exploit it. Lesson: release fixes for even potential security holes immediately :)
Oh and I'd also like to point out that Dovecot executes SSL code in nobody-chrooted environment where security holes in OpenSSL shouldn't cause much trouble, assuming OS's kernel doesn't have security holes to escape the chroot jail. If I don't trust something, I'll try make sure it doesn't have to be trusted :)
Exceptions would be nice, but I think in most cases the cleanup is just freeing dynamically allocated memory. Solution is to get rid of the free() calls. Garbage collector, memory pools, alloca(), data stack, etc. Data stack and memory pools have worked very well with my latest project. Error handling is almost always just a return call and there's hardly any wrapper functions just for handling errors. Too bad I haven't yet had time to test how well they'd work in other kind of software. I'd guess pretty well except maybe for general purpose libraries since they require a bit different way of writing C code.
I think I'll have to change the wording some more. Complex things require complex code, that's fine. If there's a security hole because the behaviour was wrong in some case, it's understandable.
What I especially don't like is that the same old buffer overflow and other memory allocation related problems come up over and over again. The 1. problem in this case was a double-free() bug. Although this is the most difficult C-related problem to solve easily (without garbage collector), with cleaner code it likely wouldn't have gone there in the first place. If you can easily see where the memory is allocated and deallocated, it's hard to screw up.
Sorry, I have already one "secure" project I am working on. I have only so much time :)
Complexity is fine, but it doesn't mean that the implementation has to be full of code that is both difficult to follow and that looks insecure at the first glance. I have looked at both GNUTLS and OpenSSL sources and GNUTLS is significantly easier to follow and it does pretty much the same thing.
Auditing depends on what you're interested in. Auditing sources for buffer overflows and other common security flaws must be easy. Auditing for crashes and more subtle bugs of course requires to be much more careful.