no you're right. This is an easy thing to find. But I also had a look at the backdoor issue and I think an audit would spot that pretty quickly too. My point of saying that it took little time to find an overflow is to suggest that this code has not been audited and it seems kind of strange to mention this particular flaw (the backdoor) when there are even more obvious flaws present. Serverity is certainly an issue. I think the backdoor is probably more severe because it is trivial to exploit. As for heads to make strcpy and the like go away, I don't know, but they would be pretty trivial:
#define strcpy STRCPY_NOT_ALLOWED_BABY!@#!@#@!
which would cause a compiler error:) A string class will get rid of trivial buffer overflows like this, certainly, but at what cost?
hmm.. maybe because "writing a parser that will example C code for security problems" is an NP hard problem, I don't know, that could have something to do with it. And yes, you do need to know how to code to look for security problems and yes, maybe a half decent C programmer can do it (although I doubt that when you consider that the Interbase code was presumably written by someone with a years experience at programming in C -- if not, what a quality product this is) but whether or not this "stupid programmer problem" is a "security problem" or not I'd dare to say that the folks who have all their data destroyed or their machine taken over as a result of it would tend to think it was. So, finally, if what you say is true and you are not a security expert then shut the hell up about stuff you know nothing about! God damn. Do you give this kind of shit to lawyers who come on Slashdot and give their legal opinion? How about processor engineers. "Hey man, I may not be a hardware engineer but it only takes someone with one years C experience to know that L1 cache is better than L2 man!".. are you aware of how stupid you sound to everyone on here who has a clue about software security? If C programmers knew what the hell they were doing then we wouldn't see dozens of buffer overflows every month.
I have no use for the software. Where's all the companies that have been using this software since day nought? Surely when they heard that Borland was open sourcing their favourite database package they should have ponied up the cash to have it done. Hell, there's probably even a couple of security companies that use this software themselves, they probably just didn't know that it was open sourced (like me!).
Apart from my previous statements about calling for companies that use the software to spring for a security audit, isn't this the same question as "who is going to pay for all these developers?" on open source projects.
Then why not make the default glibc strcpy/strcat etc safe? Or make the compiler detect overflows (now there's an NP complete problem for ya!). C is here to stay, claiming that we have to move on is not a solution. "Safe" libraries are a good start but people don't use them. Let's just make the default safe. Perhaps this is something OpenBSD would be interesting in doing?
Borland was relying on security via obscurity on this one. I don't know why no-one took this up as an issue. Perhaps I will volunteer to security audit this code (it doesn't look like much) but I am honestly of the belief that there are companies out there relying on this software to run their business. Surely they have a responsibility to contribute back to a project that they are making money from. So if you're a company and you give half a damn about security, take some of the responsibility and pay for a security audit on the source! It's in your own interests.
cool dude. I can't believe there hasn't been a serious look at this code. Their proposed solution to this problem is to change the backdoor password to something else! Now if you randomized it or did anything remotely sane this would be ok, but it's still a flaw.
Perhaps you mean it doesn't use the same backdoor password? If you are using firebird I would suggest you change these lines in interbase/jrd/pwd.c to something else for the time being (note *QUICKFIX* only). If there are any developers of firebird around I wouldn't mind hearing reasons why this isn't the same problem? What's more, the "solution" described on the home page, namely "change super secret backdoor password to something else" won't work. That's security through obscurity in the perfect form.
Well a lot of these songs do include speech you know. That's just a channel that is encoded with a speech specific compression technique (which believe it or not actually works a lot similar to compressing wind instruments). Knowledge of the domain is the key to lossy compression. So trying to compress multiple domains (different instruments and speech at the same time) is very inefficient.
actually it's more than that. They claim no remote root hacks in the default install. ie, it may very well be there but if you don't turn on the services that we have turned on by default then you're safe. That's the claim. I'm not sure about all the people who were running the ftp daemon and got exploited think. But I doubt it was "damn, I shouldn't have enabled that ftp server cause it wasn't enabled by default".
I have to be defensive, you're attacking me! I've just been flamed by five people for speaking the trueth and you can be pretty sure that none of them are security consultants like you are. Why is this not a security flaw? If I was looking through this code I would see lines like
and immediately ask "what's this LOCKSMITH thing?" and then take a grep around and discover the #define LOCKSMITH PWD_ls_user() and have a look at that and discover
{
if (strcmp(ls_pw,"Phoenix")==0)
{
mk_pwd(ls_pw);
}
return ls_pw;
}
and say "hey, this thing which is obviously a username and password is hard coded here? What the fuck?" and quickly come to the conclusion that there is a backdoor in the code. When I filed my security report I would include a section on the LOCKSMITH backdoor and when the programmers told me that they did that intentually I would have a little laugh and explain to them the risks of doing that and how to do it properly. They would tell me what is right and wrong with my proposed solution and the problem would get solved.
BTW, here we distinquish between you guys as "network security" and us guys as "software security" but I've also done network security.
Have you ever "read the code from start to finish with a pen and paper next to them" on any major project? Have you ever heard someone do that? Frequently? Or are you just trying to be a troll? That's just not the way it happens.
Actually that's exactly the way it happens. It's called a "security audit" and it involves reading the source. It is best done by a security expert who reads through the source, writes down everything that he is suspicous of and then sits the programmers down in a room and asks them question by question what each of the variables involved are, where they come from, what resultant binaries they are used in, etc. I know this because I used to do security audits for a living and it was during this actual hands on experience with software that I decided that open source was better because you can get more people reading the source simultaniously. As for whether I am trolling? No, but I appear to have attracted a few flame throwers anyway!
I don't know about "extensively", I think that should be done by someone who actually gives a damn about Interbase. Say maybe one of the companies that is using it as a crucial part of their infrastructure.. but that could be just me. I did however just download the source and spend 20 minutes on it.
I'm not trying to understand it. I'm trying to find security flaws and that that's why it's called a "security audit". And yes, finding such a security flaw is such a "subtle process" that it just took me 20 minutes to find a buffer overflow in the said source code. Why is it you seem to think you know anything about security analysis? Do you do this for a living? Well I have.
see my other post where I just discovered a buffer overflow, it took 20 minutes and I've never worked on the software. Believe it or not there are people who do this for a living, they are called "code auditors" and they perform "security audits" and it is a very local thing. You don't have to be a developer of the software, you don't have to compile the software, you just have to read the source!
The bug in question was a one byte overflow in ftpd. The guy who invented one byte overflows had this to say:
Conclusions could be drawn from this nearly impossible to exploit situation.
Although I would be surprised to hear of anyone having applied this technique
to a real world vulnerability, it for sure proves us that there is no such
thing as a big or small overflow, nor is there such thing as a big or small
vulnerability. Any flaw is exploitable, all you need is to find out how.
So even he didn't think this would ever happen and the bug in ftpd was a direct result of this. No one knew it was there because no-one knew that such a bug even existed (and if it did it was most probably not possible to exploit). That is definitely not the case here. This is an obvious flaw in security written by a programmer who obviously never thought the code would be open sourced. It should have been one of those things that you picked up on the first day and said "this is bad, you never should have done this."
Well it took 20 minutes but if you grab the file interbase/qli/dtr.c from the firebird cvs you will see one of the very first things it does in main is:
SCHAR home_directory[256];
...
#ifdef UNIX
/* If a Unix system, get home directory from environment */
startup_file = getenv("HOME");
if (startup_file == NULL)
{
startup_file = ".qli_startup";
}
else
{
strcpy(home_directory, startup_file);
strcat(home_directory, "/.qli_startup");
startup_file = home_directory;
}
#endif
That's called a "buffer overflow" and I doubt it is the only one. Just a short grep over the files gives an idea here. 642 strcpy's, 139 strcat and 945 sprintf's. The first thing to do is replace those with safe alternatives (strncpy, strncat, snprintf) and then the fun begins. And I just know that next week I'm gunna be asked to install an Interbase server:)
That is a sweet load of crap. The first day that the code was released there should have been an open security audit. This happens with other projects, why not here? A security audit involves exactly that, reading through the source. This was a trivial fault, there are probably a lot of more complex bugs (can we say buffer overflow) on the horizon.
I read it moron. I personally don't think that a year was needed to find this. I would have thought that the first day that the source was released someone would have read the code from start to finish with a pen and paper next to them and written "obvious backdoor in eight files, remove" and fixed it. I wouldn't even expect an announcement for something like this. It would just be fixed immediately and added to CVS. So the reason I'm shocked is not because Borland had a hole in their closed source (it's closed that's where security issues come from) but that for all the talk we make about peer review no-one even did a review of this code!
And BTW, I read the article and the blurb and went to the web site and downloaded the patches so I could see where the changes were made. I was actually hoping to find some sort of obsfucation in the #defines but no. It was plain as day and should have been spotted on the first day not after a year of being in the open.
Anyone wanna whip up the Perl script for this one and shove it on sourceforge? Thought not. How trivial is this? We'll pay $20,000 for your 8 lines of Perl! No. We'll pay $30,000!
You can get the security patches from the sourceforge site. What can I say? I'm shocked. Did anyone read the source? or do we just want these things open source for political reasons these days?
Slashdot Mirror
no you're right. This is an easy thing to find. But I also had a look at the backdoor issue and I think an audit would spot that pretty quickly too. My point of saying that it took little time to find an overflow is to suggest that this code has not been audited and it seems kind of strange to mention this particular flaw (the backdoor) when there are even more obvious flaws present. Serverity is certainly an issue. I think the backdoor is probably more severe because it is trivial to exploit. As for heads to make strcpy and the like go away, I don't know, but they would be pretty trivial:
:) A string class will get rid of trivial buffer overflows like this, certainly, but at what cost?
#define strcpy STRCPY_NOT_ALLOWED_BABY!@#!@#@!
which would cause a compiler error
Chalk up another Slashdot flamer. One day you will be required to think like a human being.
hmm.. maybe because "writing a parser that will example C code for security problems" is an NP hard problem, I don't know, that could have something to do with it. And yes, you do need to know how to code to look for security problems and yes, maybe a half decent C programmer can do it (although I doubt that when you consider that the Interbase code was presumably written by someone with a years experience at programming in C -- if not, what a quality product this is) but whether or not this "stupid programmer problem" is a "security problem" or not I'd dare to say that the folks who have all their data destroyed or their machine taken over as a result of it would tend to think it was. So, finally, if what you say is true and you are not a security expert then shut the hell up about stuff you know nothing about! God damn. Do you give this kind of shit to lawyers who come on Slashdot and give their legal opinion? How about processor engineers. "Hey man, I may not be a hardware engineer but it only takes someone with one years C experience to know that L1 cache is better than L2 man!" .. are you aware of how stupid you sound to everyone on here who has a clue about software security? If C programmers knew what the hell they were doing then we wouldn't see dozens of buffer overflows every month.
I have no use for the software. Where's all the companies that have been using this software since day nought? Surely when they heard that Borland was open sourcing their favourite database package they should have ponied up the cash to have it done. Hell, there's probably even a couple of security companies that use this software themselves, they probably just didn't know that it was open sourced (like me!).
Apart from my previous statements about calling for companies that use the software to spring for a security audit, isn't this the same question as "who is going to pay for all these developers?" on open source projects.
484961 lines in .c files
.h files
.e files (like a script file)
395521 lines in
116496 lines in
you call this big? From a security analysis point of view, this is a baby.
Then why not make the default glibc strcpy/strcat etc safe? Or make the compiler detect overflows (now there's an NP complete problem for ya!). C is here to stay, claiming that we have to move on is not a solution. "Safe" libraries are a good start but people don't use them. Let's just make the default safe. Perhaps this is something OpenBSD would be interesting in doing?
Borland was relying on security via obscurity on this one. I don't know why no-one took this up as an issue. Perhaps I will volunteer to security audit this code (it doesn't look like much) but I am honestly of the belief that there are companies out there relying on this software to run their business. Surely they have a responsibility to contribute back to a project that they are making money from. So if you're a company and you give half a damn about security, take some of the responsibility and pay for a security audit on the source! It's in your own interests.
cool dude. I can't believe there hasn't been a serious look at this code. Their proposed solution to this problem is to change the backdoor password to something else! Now if you randomized it or did anything remotely sane this would be ok, but it's still a flaw.
Firebird doesn't have the problem!? Then why on their web page do they have the advisory? And what is this code that I just pulled from the CVS doing?
char *PWD_ls_user()
{
if (strcmp(ls_user,"Firebird ")==0)
{
mk_pwd(ls_user);
}
return ls_user;
}
char *PWD_ls_pw()
{
if (strcmp(ls_pw,"Phoenix")==0)
{
mk_pwd(ls_pw);
}
return ls_pw;
}
Perhaps you mean it doesn't use the same backdoor password? If you are using firebird I would suggest you change these lines in interbase/jrd/pwd.c to something else for the time being (note *QUICKFIX* only). If there are any developers of firebird around I wouldn't mind hearing reasons why this isn't the same problem? What's more, the "solution" described on the home page, namely "change super secret backdoor password to something else" won't work. That's security through obscurity in the perfect form.
yer sorry dude. I misread it.. as the flames around your civil comment state :)
Well a lot of these songs do include speech you know. That's just a channel that is encoded with a speech specific compression technique (which believe it or not actually works a lot similar to compressing wind instruments). Knowledge of the domain is the key to lossy compression. So trying to compress multiple domains (different instruments and speech at the same time) is very inefficient.
actually it's more than that. They claim no remote root hacks in the default install. ie, it may very well be there but if you don't turn on the services that we have turned on by default then you're safe. That's the claim. I'm not sure about all the people who were running the ftp daemon and got exploited think. But I doubt it was "damn, I shouldn't have enabled that ftp server cause it wasn't enabled by default".
I have to be defensive, you're attacking me! I've just been flamed by five people for speaking the trueth and you can be pretty sure that none of them are security consultants like you are. Why is this not a security flaw? If I was looking through this code I would see lines like
return (!strcmp (name, "USER") && !strcmp (project, "LOCKSMITH"));
and immediately ask "what's this LOCKSMITH thing?" and then take a grep around and discover the #define LOCKSMITH PWD_ls_user() and have a look at that and discover
char *PWD_ls_user()
{
if (strcmp(ls_user,"Firebird ")==0)
{
mk_pwd(ls_user);
}
return ls_user;
}
char *PWD_ls_pw()
{
if (strcmp(ls_pw,"Phoenix")==0)
{
mk_pwd(ls_pw);
}
return ls_pw;
}
and say "hey, this thing which is obviously a username and password is hard coded here? What the fuck?" and quickly come to the conclusion that there is a backdoor in the code. When I filed my security report I would include a section on the LOCKSMITH backdoor and when the programmers told me that they did that intentually I would have a little laugh and explain to them the risks of doing that and how to do it properly. They would tell me what is right and wrong with my proposed solution and the problem would get solved.
BTW, here we distinquish between you guys as "network security" and us guys as "software security" but I've also done network security.
Have you ever "read the code from start to finish with a pen and paper next to them" on any major project? Have you ever heard someone do that? Frequently? Or are you just trying to be a troll? That's just not the way it happens.
Actually that's exactly the way it happens. It's called a "security audit" and it involves reading the source. It is best done by a security expert who reads through the source, writes down everything that he is suspicous of and then sits the programmers down in a room and asks them question by question what each of the variables involved are, where they come from, what resultant binaries they are used in, etc. I know this because I used to do security audits for a living and it was during this actual hands on experience with software that I decided that open source was better because you can get more people reading the source simultaniously. As for whether I am trolling? No, but I appear to have attracted a few flame throwers anyway!
I don't know about "extensively", I think that should be done by someone who actually gives a damn about Interbase. Say maybe one of the companies that is using it as a crucial part of their infrastructure.. but that could be just me. I did however just download the source and spend 20 minutes on it.
I'm not trying to understand it. I'm trying to find security flaws and that that's why it's called a "security audit". And yes, finding such a security flaw is such a "subtle process" that it just took me 20 minutes to find a buffer overflow in the said source code. Why is it you seem to think you know anything about security analysis? Do you do this for a living? Well I have.
see my other post where I just discovered a buffer overflow, it took 20 minutes and I've never worked on the software. Believe it or not there are people who do this for a living, they are called "code auditors" and they perform "security audits" and it is a very local thing. You don't have to be a developer of the software, you don't have to compile the software, you just have to read the source!
So even he didn't think this would ever happen and the bug in ftpd was a direct result of this. No one knew it was there because no-one knew that such a bug even existed (and if it did it was most probably not possible to exploit). That is definitely not the case here. This is an obvious flaw in security written by a programmer who obviously never thought the code would be open sourced. It should have been one of those things that you picked up on the first day and said "this is bad, you never should have done this."
Well it took 20 minutes but if you grab the file interbase/qli/dtr.c from the firebird cvs you will see one of the very first things it does in main is:
:)
SCHAR home_directory[256];
...
#ifdef UNIX
/* If a Unix system, get home directory from environment */
startup_file = getenv("HOME");
if (startup_file == NULL)
{
startup_file = ".qli_startup";
}
else
{
strcpy(home_directory, startup_file);
strcat(home_directory, "/.qli_startup");
startup_file = home_directory;
}
#endif
That's called a "buffer overflow" and I doubt it is the only one. Just a short grep over the files gives an idea here. 642 strcpy's, 139 strcat and 945 sprintf's. The first thing to do is replace those with safe alternatives (strncpy, strncat, snprintf) and then the fun begins. And I just know that next week I'm gunna be asked to install an Interbase server
That is a sweet load of crap. The first day that the code was released there should have been an open security audit. This happens with other projects, why not here? A security audit involves exactly that, reading through the source. This was a trivial fault, there are probably a lot of more complex bugs (can we say buffer overflow) on the horizon.
I read it moron. I personally don't think that a year was needed to find this. I would have thought that the first day that the source was released someone would have read the code from start to finish with a pen and paper next to them and written "obvious backdoor in eight files, remove" and fixed it. I wouldn't even expect an announcement for something like this. It would just be fixed immediately and added to CVS. So the reason I'm shocked is not because Borland had a hole in their closed source (it's closed that's where security issues come from) but that for all the talk we make about peer review no-one even did a review of this code!
And BTW, I read the article and the blurb and went to the web site and downloaded the patches so I could see where the changes were made. I was actually hoping to find some sort of obsfucation in the #defines but no. It was plain as day and should have been spotted on the first day not after a year of being in the open.
Anyone wanna whip up the Perl script for this one and shove it on sourceforge? Thought not. How trivial is this? We'll pay $20,000 for your 8 lines of Perl! No. We'll pay $30,000!
actually yer.. I suppose a year is not bad to take notice of a known backdoor account and say "hey.. this is kind bad isn't it?".
You can get the security patches from the sourceforge site. What can I say? I'm shocked. Did anyone read the source? or do we just want these things open source for political reasons these days?