Slashdot Mirror
Interbase Backdoor, Secret for Six Years, Revealed in Source
Diesel Dave writes "CERT Advisory CA-2001-01 announced today that the Interbase server database contains a compiled-in back door account. The thing is, it was not the result of a malicious code infection, but a direct addition by the original Borland/Inprise authors done before the program was released as open source." The backdoor was installed sometime between 1992 and 1994, and has been included in every version of Interbase during that time.
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.
How we know is more important than what we know.
Comment removed based on user account deletion
Linus Torvalds
I'm sorry, but I just had to comment. When I saw your sig, the following line just popped into my head.
"Me, the creator of the Linux Kernel? in las Vegas? with showgirls? What were they thinking?"
People who've seen "The Fast Show" ("Brilliant" in the US) will know what I'm talking about.
Rich
You aint seen me, right!
If you feel so strongly that every open source program should go through a security audit, then when is the last time you volunteered to do one? Opensource is about people volunteering their time which is often in competition with their real jobs, lives, families etc. In a perfect world, all software would go through a security audit, but it is not going to happen.
At least with opensource, things like this get found. Obviously Borland's security audit didn't find it when they originally released this as a commercial product! If it wasn't for opensource, this would probably still be being silently exploited by the original programmers and the few people they told.
And who's going to pay the expense of an audit on a few hundred thousand lines of code when there are several other open source databases out there that are more popular, which hopefully, but not necessarily, means they have this kind of thing in them.
I recently asked someone about Internet privacy and security and got the best answer I ever did.
Privacy? Security? There isn't any, stop deluding yourself.
If you have secrets, find another way to keep or tell them.
To the Moon!
http://www.beefjerky.com
I have a windoze box to edit videos on; I also use it occasionally to check e-mail and ftp, and so even though I don't have an always-on internet connection, I installed a firewall. And so I discovered that even though I told *everything* installed that I would update manually, Internet Explorer and Windows explorer still want to connect to the internet any time I log on. god only knows what else Media Player is communicating as I listen to the radio. I guess now I need a packet sniffer and a few days of free time. or an antennae that can pick up stations in Greece from North Florida. :-)
User: Field Password : Engineer
Compiled-in? I don't think so. That account ships as one of the default accounts (along with SYSTEM/manager), and exists so that the installation crew can do their job. Field circus accts should always be disabled until the CSE arrives, then re-authorized with a random password for the duration of the maintenance, and then changed as soon as the CSE leaves the premises.
Just junk food for thought...
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.
How we know is more important than what we know.
This is probably just an urban myth. With the amount of personal firewall software people are running these days someone would have logged the unauthorized data being transmitted and their would be sufficient evidence to get M$ in a whole load of shit.
You must not be a programmer, because reading a program from 'start to finish' is an assinine way to understand it. In addition, it is impractical because the source for Interbase is probably several hundred thousand (million?) lines of code. Finally, reading it from start to finish would not cause a 'backdoor' bug to be found. It is unlikely that there is a function called login_backdoor(), so finding such a security hole is a subtle process.
For a program as complex as Interbase I am not surprized that it took a year for someone (outside Borland) to understand it enough to find the 'back door'.
Later
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
Well, you could change it with a hex editor but it still sucks.
---
where there's fish, there's cats
OpenBSD has been undergoing a security aduit for years. A couple months ago they were able to claim there had been no known root hacks in the current release for 3 years. (That is they were able to fix root hacks before they were discovered for the last 3 years). Well sometime this summer someone discovered a root hack in the released system, despite all those audits. (To be fair, they had fixed that hole in the unreleased code stream, nobody realized it was exploitable at the time though so there was no hurry to release it early).
Audits are good, but they take time. OpenBSD has proven they take a lot of time. There is no open source project with as much work in security auditing as openBSD. (Probably no closed source project either). No open source project cares are much, yet they can't always get it right despite 5 years of work. To criticie any other project for not discovereing all secuirity holes is a mistake. Even if the openBSD audit team had decided to work on this with as much effort as went into openBSD there is no reason to belive they would have discovered this sooner.
They aren't just paying for 'high-quality' apps.. they're paying to cover their asses so that if something like this was found in a commercial app, they have financial and legal recourse. A bug like this can conceivably cost a company millions in bug fixes, lost revenue and invalidated contracts. I wonder how many business contracts have involved what amounts to vouching for open source code bases that nobody at the company has audited or even skimmed over.
In the case of root, the existence of the backdoor is well known, but the details (password) are nominally only known by a few people. On some systems, the 'root' name is changed to something else (e.g. toor) for obscurity reasons.
In the case of Inprise, the existence and details of the backdoor were known to external persons (developers) but unknown by the actual user and the details are unchangable without source code. (note: it looks like a quick fix here would be to edit the backdoor details in the source and recompile). This was entirely 'security by obscurity' and, now that the cat is out of the bag, almost every user of the software is at risk.
Point to be made here: Opening the source code simply made it much easier to find the backdoor. Overall, I think that this is a good thing. There may be some hackers out there who knew of this backdoor for many years. Now we have the knowledge and impetus to clean it up.
I don't think that this was a malicious backdoor. The design of the software seemed to require it (oops!). The big mistake is that nobody who had access questioned it's existence. The lesson to be learned is that people who have access to source code and see this sort of stuff should make waves to open up the process.
The best gemeric solution is to remove the need for internal 'backdoors' in code. That being infeasible, the software should be changed so that the details of the backdoor are editable by the end-user (or randomized on every start of the software). Obviously, the user has to be made aware of the need to edit this data. That solution, of course, has its own security implications (exercise for the reader).
`ø,,ø!
Free Software: Like love, it grows best when given away.
I have two machines linked together by an crossover ethernet cable. Can you hack into that network? I'd be impressed if you could
A fairly simple manner of splitting the cable and installing my own junction, or attaching my laptop to one of your machines via a serial port
Anyway, as soon as I saw your comment, I got into your master server (which I noticed connected to the Internet on 127.0.0.1 hah!!), and have told the police about your massive pr0n and war3z collection! You should now notice your hard disk is thrashing as my rm -r * takes affect suX0r!
Whoops! Hangon? Why is MY disk thrashing
Note that binary patches for the commercial version have been written by the same guys who found the back door in the first place. Check HERE: http://64.55.62.15/s .html
I think you can trust them.
For more information, follow the links on www.interbase2000.org
These are most likely different from the official Borland patches, which are at: http://www.borland.com/interbase/downloads/patche
Have you worked on any Open Source projects, or have you seen what happens when a previously closed source project gets released? Strange as it may sound, there is a bit of reverse engineering that must take place, especially if this bundle of source is not brilliantly commented and documented.
In this case, it was worse, because when Interbase was Open Sourced, it was not buildable. Important scripts, Makefiles, and other assets were missing. So, you had this whole mess of random source that you could begin to guess the function of, but if you hadn't been a former Interbase developer at Inprise, it was all a black box to you.
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.
Personally, I'm impressed that they've been able to find this. I mean the Firebird project found a working binary from Inprise and a collection of code rumored to, through some magic process, produce that binary. They worked out the magic process, produced their own binary, and moved on from there.
Only then, after they had source code corresponding to a working program could they start doing the poking and reverse engineering it took to figure out the parts and the places. They had some luck, since they do have the original creators of Interbase on their side, but there were quite a few hurdles to go through before they could even start to make heads or tails of what they were looking at.
Then again, I dunno, maybe I have it all wrong and these guys were just sitting on their thumbs all day.
There is a fundamental problem at the root of this, which is that the C standard library is hideously irregular, and the C language itself is not meant to be "safe". It's an okay language for writing hardware drivers and other low-level system components, but a safer, more abstract language would be a better choice for applications.
Rich
Taco cleaned up his code?
Special Relativity: The person in the other queue thinks yours is moving faster.
I trust that the next time a significant source release of this kind is done that you, personally, will download the source and study it exhaustively in this fashion.
Which is, of course, the complete opposite of what you said.
/. comments, because no mistake ever goes uncorrected. I had assumed from reading the security notification that the password was placed in the source just before it had been open sourced. As the yanks say, my bad. It was placed in the original program years ago, but only opensourced one year ago, and that was what led to the backdoor being discovered, I've got that now. I wonder how many people have taken advantage of this over the years.
Which is why I like
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
Is it a good thing or not?
Is there a good use for back doors?
I'm from Argentina: Tango, Asado, Mate, Gaucho, Maradona, YPF
You are wrong about the time aspect, the second any backdoor is introduced, there is a security problem - not when someone other than the person that coded it finds it.
That is the big difference - in an open source project, a security flaw is accidental, and not exploitable until someone finds it - and hopefully it is the comunity that finds it and not a hacker. With a backdoor in a closed source project, security is broken immediately. The person that coded it knows about, his friends, the person that asked him to put it there, etc....
I have come to a conclusion that one useless man is a shame, two is a law firm, and three or more is a congress -J Adams
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
How we know is more important than what we know.
Why is cert using https to publish advisories? My version of Netscape can't browse to their site because it and their site does not share a common encryption algorithm. Is there a plain-jane http: version of this URL?
-russ
Don't piss off The Angry Economist
Anybody running a pre-open-source Interbase seems to have only really unpleasant choices:
I'm glad I'm not in that position.
CVS is teh suck. Use Vesta instead.
With what ever you want. The point is that it can be traced and checked. Assembly "source" can be mapped 1 to 1 with the binary code. This allows you to check and to confirm that it is doing what you want and no more. This is not possible with compiled binaries because the structure is you need to check it is lost during the compile. This is not an easy thing but it can be done.
Oh.. So what you're telling me is that the backdoor was SECURED? Hehehe :)
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
That is the big difference - in an open source project, a security flaw is accidental, and not exploitable until someone finds it - and hopefully it is the comunity that finds it and not a hacker.
Why is it that you think the security flaws in open source are all accidental, while the ones in closed source are all by design. There's no reason an open source developer couldn't hide a designed security flaw in an open source project. I'm sure it's harder, but it can still be done. There's security flaws found in open source software all the time. If they can get in there accidently, then some one could design them in just as well.
No backdoor there. What they do is run a binary editor program upon the raw data files while the database engine is shutdown.
The only way to find it was to dis-assemble the compiler and codewalk the result.
You're assuming that the disassembler wasn't also in on the joke, and that it it wouldn't recognize that it was disassembling the compiler and casually omit the incriminating code. For that matter, you're assuming that the C compiler wasn't smart enough to recognize when it was compiling a disassembler and insert the appropriate code to implement the above.
There are two questions to ask yourself: "am I being paranoid?" and "am I being paranoid enough?".
-- Alastair
Correction: how many years it took anyone to discover and announce this. Just because it was only now announced doesn't mean someone didn't know about it two years ago and kept quiet about it.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
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."
How we know is more important than what we know.
Godwin's Law! This thread is now over.
The Signal/Noise ratio can be improved in two ways. Remaining silent is the OTHER way.
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.
How we know is more important than what we know.
It's not laziness I think. I think it is a lack of knowledge about these issues. Ignorance of security causes most of these issues and it is not suprising. I have done a lot of formal education in programmer and never once have I been formally taught anything about security issues. I have read lots of books about programming, but never once have I read (in a book) about security issues. Actually I've never seen a book about security issues that wasnt jam packed full of cryptography.
How we know is more important than what we know.
a GPL version would be the key thing here. You need to be able to see the assembled and the binary to confirm this compiler.
Unless source-safe was hacked :-)
That's assuming MS use their own products of course....
----
I hereby inform you that I have NOT been required to provide any decryption keys.
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!
How we know is more important than what we know.
In order to stop a compiler from adding any thing to your program is to compile the compiler from source code
Unless the compiler source has no obsticated backdoors of course.
The solution is to have a basic compiler written in Assembler. This way you do not need to start with a binary compiler that you can know with 100% is clean of any bad things
And now you assume that more than about 1% (if even that) of the programming community have the skill to analyze 20000 lines of assembler looking for backdoors! I'd much rather try and find a backdoor in 30000 lines of C than 20000 lines of assembler.
A couple months ago they were able to claim there had been no known root hacks in the current release for 3 years.
actually, it was no known root exploits in the default install for three years.
Well sometime this summer someone discovered a root hack in the released system, despite all those audits
i beleive this was resolved when some one told the guy that ftpd (the daemon that contained the buffer overflow he was exploiting) was not enabled by default.
[exerpt of note sent to bugtraq]
In that mail, he first pointed out that "your 3 years of remote safeness
have just ended", and then provided technical information for fixing a
serious ftpd bug. But he made a minor error that made the fix ineffective.
He also said that he knows of a private exploit for this vulnerability, and
in another mail pointed out that Scrippie was the one who found the bug.
The first reply that came was a short one:
"ftpd is not enabled in the default install since 2.6."
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.
How we know is more important than what we know.
Nah, these are not permanent ACLs, just added on for a few weeks to see what kind of a problem this might be for downstream clients. They'll get removed after we see what is going on. Over the last few days, we've seen the exact same signature from a script, sequentially probing IP addresses to port 3050. We're using private I to capture and filter the logs so if we get asked by a clueless manager at some later date if we were doing our jobs, we can hand them a pretty report.
:-)
:-)
Now that I know what to simulate, I'll rig one of the honeypots and see if the script tries the exploit, or if the crackers wait until later after a positive hit to try their luck. But that will wait until tomorrow, beer is calling
And besides, if I ever choke out one of the routers, its good justification to accounting to buy bigger routers
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
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.
How we know is more important than what we know.
I wonder about MS SQL Server too. Their code is a branch from Sybase's ASE server and Sybase released an urgent security alert advisory for all platforms in September 2000. They gave no details on what the problem was but said "Sybase views this as a mandatory correction that you should implement immediately." Database servers presumably have very big source trees (the stripped ASE executable for Solaris is 11MB) and it must be relatively simple to hide a backdoor in the source code that could lie undiscovered for years. Here's their security advisory from Sept 2000.
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.
How we know is more important than what we know.
No I am not a security expert. IMHO, understanding how a program works is an obvious pre-requisite to find security flaws. You cannot understand how a program works simply by reading the code.
In the Interbase example, (I could not read the CERT advisory before my post), it may have been easy to find, maybe not. Quite possibly, no one looked at or read those modules, or (more importantly) understood the code to determine that it was a back door.
Your buffer overflow example is pointless. Anyone with 1 year experience as a C programmer can find a buffer overflow. IMHO - this is not a 'security problem', it's a 'stupid programmer problem' - i.e., competent programmers check memory boundaries.
As far as grepping around the code, fine - write some shell scripts and have a party. If you are so worried about it, why didn't you read the Interbase code from 'start to finish'. Or better yet, write a parser that will examine C code for security problems. This would be a hell of a lot more useful to perform security audits, compared to reading the code from 'start to finish'.
Later
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
I'm sure you realize that whatever you used to compile your own compiler could also include a well-hidden binary backdoor. Something like this is recursive. The only way to be secure is to use hardware which you built yourself, with an operating system and compiler which you wrote yourself by hand, and even then, you must be able to trust the tools you used to build that hardware and enter the base code.
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!).
How we know is more important than what we know.
or you play the (mostly) crap games that you CAN get under the GPL.
You downplay the "mostly." I admit, many GPL'd games are crap, but most commercial games are crap too. You just have to find the diamonds in the rough. For instance, have you ever experienced tetris... on LSD? Or have you raced down a mountain as a penguin? Or taken out your frustration by killing those annoying little hampsters?
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Actually, they didn't forget about it. One of the developers used it to implement a feature in version 6, the current version. The original solution by the self same developers (sent to the world when they forgot to purge their internal CVS notification list) was to change the backdoor account and password and just not tell anyone (they apparently aren't aware that an image can be dumped in ascii). Now they claim a different fix. But this time they're not telling anyone (me, you, the users or even CERT) how they closed the back door.
I think Firebird probably forgets to mention that the "original" developers released Interbase to the open source knowing fully that the backdoor was there waiting to screw Borland at a later time. Just a thought because now they look like the good guys. Granted they did a good thing, but this just makes Borland look bad in the public eye.
This brings up the question, to view from several angles, how would you try to sneak in a back door (or any kind of 'easter egg' type code that doesn't need to be there) into an open source project? Obscure hashing of keys in the code? Just naming functions so they sound official?
There can't be a way to completely hide it. Just make the trail harder to follow. So, as an exercise of what to look for, how would you go about pulling something like this off?
Jason
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!
How we know is more important than what we know.
hey fuckhead. Someone DID read the source, that's why it was found. My god, are you dumb? Or are you volunteering to fish through the thousands and thousands of lines of code of every closedsource project that goes open? Thought so. This is proof that eventually it will be found in an opensource setup. It may never, ever be found in a closed source situation. Just ask any professional developer how much of a pain in the ass it is to read through someone elses code with what little comments they left, and try to get a grip on EVERYTHING thats going on.
Yea, I thought so.
In which case, it shouldn't take much more than applying "strings * | less" and some careful reading before and after the patch to find out the new backdoor account.
And yes, it is probably unencrypted; I just checked version 4 binaries on freebsd and these two files have it unencrypted:
-r--r--r-- 1 root wheel 1145637 Oct 22 1998 gdslib.so.0.1
-r--r--r-- 1 root wheel 1145835 Oct 22 1998 gdslib.so.1.0
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
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
... I'd be looking at at least a 5 day penetration test for that!
A code backdoor is NOT a "security flaw"! Any decent C programmer can spot a buffer overflow in 20 minutes, but very few programmers could spot an obsticated backdoor in a major application like a relational database system without a major investigation by a dedicated team of people!
Why is it you seem to think you know anything about security analysis? Do you do this for a living? Well I have
Well I'm a security consultant and could probably spot a hole in a set of firewall rules in 20 minutes, but it doesn't mean I could find a route through a unicode vulnerability in a www server, which accesses an open share on another server, which has trusted access through another firewall to a back-end Oracle system in 20 minutes
Please stop being defensive, and stand back and look at this particular situation!
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.
How we know is more important than what we know.
Rich
There is a very good fix at http://firebird.ibphoenix.com The fix is an image zapper that finds and replaces the account, password, and the doomsday function with randomized byte strings. It's available for all almost all platforms and works for all versions of Interbase, except for the latest Firebird, which doesn't have the problem. The zapper, named ibsecure, is also ready to zap the anticipated new backdoor in Borland's latest release. Oh, maybe they did do a profession job this time? But since they're not talking, who knows?
Chalk up another Slashdot flamer. One day you will be required to think like a human being.
How we know is more important than what we know.
It worked for 6 years. How much longer would it have worked if they hadn't opened their source?
Of course you don't want obscurity to be your only method, but you shouldn't rely on peer review as your only method either. It's just that I've grown tired of people saying that obscurity is of no value at all.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Now that I know what to simulate, I'll rig one of the honeypots and see if the script tries the exploit, or if the crackers wait until later after a positive hit to try their luck. But that will wait until tomorrow, beer is calling :-)
:-)
....!
They actually let you run a honeypot? You lucky thing! The chances of me actually managing to produce a business justification for one are pretty slim. Management happily spend money on top-end NetRangers etc. which is nice, but this is one step too far for them!
And besides, if I ever choke out one of the routers, its good justification to accounting to buy bigger routers
Extremely good point: like accounting would ever understand that processor saturation is down to multiple ACLs
https://www.cert.org/advisories/CA-2001-01.html- -
-----------------------------------------------
Jobs? Which jobs?
If all they did to fix this was randomize the password in the binary, and the password is stored at the same offset in every binary, isn't it trivial to find the randomized password by reading the binary file?
Last I looked most executables were readable by world.
>"BACKDOOR_PASSWORD\0My_Sekret_Password\0"
Rich
The backdoor was introduced in the commercial version of the software. It's only now that it is open source that we could even see the error. The people paying for the 'presumably...high-quality app' you extoll the virtue of were receiving the backdoor-enabled product. Rather than being a failure of open-source software, I'd say this one was a sucess. I only wonder what other kind of 'crap' exists in all those apps whose sources are closed.
I've thought about this before, and I shiver. Who is to say that big brother Bill Gates doesn't have a backdoor for everything MS. We'll never know, unless someone accidently finds out and leaks it to the public (I don't see MS going open src ever). So if everything MS could have a backdoor, what about the La-Z-Boy featured yesterday? (This answers the question of "why doesn't the recliner come with a toilet installed?")
We administer hundreds of users here and have just such a back door account. We call it 'root'.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
I don't think you undestand the nature of the "patch". The program is an image zapper that replaces the compiled in account/password with randomized strings. The problem with that technique is that a counterfeit zapper could replace the known back door with an unknown backdoor. The most effective way to prevent counterfeit zappers is to insist that people down load their own zappers.
grep -R 'obvious backdoor' `find . -name '*.[ch]' -print` | Mail -s 'Fix these' me
(It's a one-liner. Re-assemble if necessary. Modify appropriately for other languges.)
anybody who takes this seriously deserves to .
`ø,,ø!
Free Software: Like love, it grows best when given away.
When she later spoke with someone from InterBase R & D, the "fix" he described was merely a change to a string - no fix at all.
MadAhab wrote:
That seems to indicate that they DID just switch passwords.
Ok, I was a bit unclear on who said what. But it was the InterBase folks at Borland ('he') who did the 'change passwords' trick, and the Interbase2000 people ('she', Open Source people) discovered it and called it a no-fix.
This is, of course, no proof that the patch doesn't just change the password...
M.
ARMAGEDDON! ARMAGEDDON!
That was just disturbing...
Yeah, and a Mack truck will kill 99% of known household pests, too.
Why is there only one Monopolies commission?
A couple of things about this story -- and points raised in earlier posts are interesting in light of the NSA's recent release of a secure Linux. First: A backdoor that had existed for years was discovered relatively quickly (hey -- nothing happens overnight) after the code was opened up and began to see common use. Second: As others have pointed out, security by obscurity does work after a fashion and up to a point. Trouble is, so does vulnerability by obscurity.
See, that's not even a troll, that's just pure stupidity. The point of the sig line is that, because it is sold on the black market, pot is so damn expensive that people go out and steal stuff to get the money. And this is about the cheapest of contraband drugs. Now shut the fuck up.
How we know is more important than what we know.
http://64.55.62.15/home.nfs?a=ibphoenix&s=97925959 7:1&page=starkey
It shure gives a good argument for Open Source in security critcal locations. What if the same exists in Exchange or ISS?
If bBrland could have it, why not Oracle, Sun, IBM? (Well to be honest you could get the source for Solaris from Sun.)
/ Balp
No, the senior developer currently on the project was present when the back door was implemented, and used the back door during development of the most recent version (V6). He just didn't think about the implications.
There is a big difference -- these are not hidden. They are there to install and test the server and if you don't change them before you actually start using the server, then you are the stupid one. In this case, Borland is stupid.
I have a woman and money. Life is good.
What's even funnier is blocking IE on Win98+ from making outgoing connections. It went nuts on me the first time I connected after that, but it's just been sulking quietly ever since. Opera forever, baby...
Yeah, the IBPhoenix/Firebird guys are real heroes. We have a lot to thank them for:
/. or the Interbase and Firebird newsgroups and mailing lists. These sites are screwed now.
* They (Jim Starkey) revealed the backdoor to the public before a fix was in place. They didn't reveal the actual username/password, but they made it very clear where, how and what to look for. After that most people found it in no time.
* Either they panicked or saw this as their chance for 15 minutes of fame. Given that this backdoor has gone unnoticed, and presumably unexploited, for years they could have worked with Borland to come up with a solution and had this solution distributed to the customers before the problem was publicised. The majority of Interbase sites are end-users who do not read CERT alerts,
* Presumably they *did* try to work with Borland, but who did they send to make the contact; The people in the IBPhoenix/Firebird community who hates Borland the most and who uses every chance they get to harm Borland; Ann and Jim. That Borland refused to speak with them can hardly come as a surprise to them given their common history during the last year. If my company where the target of Ann and Jim's attacks, I too would forbid all contact with them.
* They (Jim again) repeatedly insult and slander Borland and the people who works or has worked on the Interbase development team, thereby making cooperation between Interbase and Firebird close to impossible. They don't seem to care that if they succeed in making Borland and Interbase look bad, they will probably scare the existing, paying, Interbase users away, leaving Interbase/Firebird with a fraction of the popularity is has now.
* They have made sure that Borland will think twice before they ever release another of their products as Open Source. Borland has received nothing but bad will from the IBPhoenix/Firebird community since the source was released (and even before that). People seem to forget that in reality they don't have the right to claim anything from Borland. Interbase is Borland's property and they should be grateful for anything they get for free. Borland could have deep-sixed Interbase but they didn't. Is IBPhoenix/Firebird happy about that? Oh no, they are mad at Borland because Borland *might* have deep-sixed it. Ann and Jim had their chance with Interbase a long time ago and they sold it on their own free will. Yet Jim continue to behave as if it's still their database and that all the improvements that have been done to it since then are crude unworthy hacks made by the incompetents at Borland. If I had believed a fraction of the negative propagande I've read on the Interbase-Architect list (used primarily by Firebird), I would have abandoned Interbase long ago and moved to Oracle or MS-SQL.
That said, yes, the backdoor is a security flaw, it shouldn't have been there in the first place and even though I don't know the details of what problem it was supposed to fix, it was evidently a stupid solution.
It would have been nice if the implications of the backdoor had been analyzed before the problem was publicised. The CERT alert and the biased description on the interbase2000 site makes the problem sound like a doomesday machine, but from what I have been able to determine, it is actually quite limited what one can do through the backdoor account. I have been able to attach to an Interbase server and retrieve meta-data, but that's it; I have *not* been able to view, insert, delete or modify data, I have *not* been able to create, modify or delete meta-data and I have *not* been able to add, modify, drop or execute stored procedures. There *are* reports that some people have been able to crash the database process by attempting some of these operations. If that's the scope of the security problem, I personally can live with it.
-- Sue me if I'm wrong
Whether it's profit-driven, back-doors, or mass-murder: How often have you heard the phrase:
"That's just the way we do things."?
`ø,,ø!
Free Software: Like love, it grows best when given away.
First, the Interbase code has only been out for about six months. Second, Borland didn't tell anyone. The problem was found by a member of the Firebird community. Third, it was found by reading the source. Heartening.
I want any non-system application (ie fingerd, bind, apache, etc.) written in a SAFE language so that these kinds of common, braindead errors are IMPOSSIBLE.
The "trusted" unsafe C codebase should be as small as possible.
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.
How we know is more important than what we know.
I wouldn't be surprsised that the "breakins" into databases recently where millions of cc numbers were compromised were rooted in similar situations.
It's really given me cause for entrusting my financial data to any online merchant. As such, I make a concerted effort to only use one cc for online purchasing, which I periodically "lose" so I get a new number.
I recommend you all do this.
-- You see, there would be these conclusions that you could jump to
Ok, I agree that there might be some good reasons to plant backdoors on software but the costumer must be informed that it's possible to the vendor to access costumer data/system.
There was a blurb about Microsoft being able to access Win95 registry when a user is connected to the Internet and thus gathering information about non-licensed MS software installed. I don't know if it's true but is the kind of procedure I'd expect from Redmond and that I think it's extremely wrong.
If C programmers knew what the hell they were doing then we wouldn't see dozens of buffer overflows every month.
My original point is that merely reading the code is not the only way to find all security flaws. If it were, then writing a 'parser to examine C code for security problems' would be a snap. Since you stated that this is a hard problem, then you must acknowledge that you cannot just read the code from 'start to finish' and say you have completed the security audit. Surely, you security experts actually run programs and try to break them, right? If not, then you are utterly clueless.
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...
Your presumption of the competence of C programmers (at Interbase) or otherwise speaks to your ignorance about building programs and the number of flaws per lines of code. Buffer overflows are so pervasive in C code because of two things: 1. incompetent test cases and 2. clueless programmers. For example, clueless programmer Joe writes code that does not check for overflows. Clueless Joe never runs a test case run which exploits the overflow, so he thinks his code is 'all clear'. Clueless Joe moves onto the next project and repeats cycle.
The bottom line is that programmers (like security experts) are fallable. Sometimes the fallability is a matter of incompetence/ignorance (mostly) or laziness (rarely).
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
They claimed no remote root hacks.
It is not exactly the same as no root hacks, is it?
Ni!
Just because you didn't know about the backdoor doesn't mean that some cracker didn't know about it.
Deleted
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".
How we know is more important than what we know.
Before I start, I've never had anything to do with this project so I'm taking a lot of what you say at face value.
/. or the Interbase
....
...
>* They (Jim Starkey) revealed the backdoor to the
>public before a fix was in place. They didn't
>reveal the actual username/password, but they
>made it very clear where, how and what to look >for. After that most people found it in no time.
Where is there any reference to this? They actually waited until after Christmas and a patch in place before releasing any information and after repeated attempts to contact Borland.
>Either they panicked or saw this as their chance
>for 15 minutes of fame. Given that this backdoor
>has gone unnoticed, and presumably unexploited,
>for years they could have worked with Borland to
>come up with a solution and had this
>solution distributed to the customers before the
>problem was publicised.
And if someone had found the exploit while the patch was being distributed (not unlikely, You get a patch from Borland with instructions to install it urgently. Your database works fine now. Why bother)? Or if someone had noticed it in the unpatched source?
>The majority of Interbase sites are end-users
>who do not read CERT alerts,
>and Firebird newsgroups and mailing lists. These
>sites are screwed now.
And that's the firebird teams fault how? If there are still people out there who aren't willing to take the effort to watch the accepted security advisary mailing lists then they deserve what they get.
>Presumably they *did* try to work with Borland,
>but who did they send to make the contact; The
>people in the IBPhoenix/Firebird community who
>hates Borland the most and who uses every chance
>they get to harm Borland; Ann and Jim.
They hated them sooo much they went out of their way to provide binary patches when the patch that was released by Borland was a non-patch. And they even attempted to contact them at all. They could have just gone to CERT with the advisory, Borland be damned. Borland looks like a criminal for putting a backdoor in their software and the firebird team look like saviours. No extra effort needed.
>That Borland refused to speak with them can
>hardly come as a surprise to them given their
>common history during the last year. If my
>company where the target of Ann and Jim's
>attacks, I too would forbid all contact with
>them.
So petty bickering is more important to Borland than their customers security. There's a customer attitude to be proud of. If you received an email from someone that explained the discovery of a major security hole in one of your products would you think "Now the boss said not to talk to these bad people so I'm just going to delete this email". I think not.
> They (Jim again) repeatedly insult and slander
> Borland and
[snip]
I can't argue with you here I don't know the full story but petty bickering vs huge security hole. Weigh it up.
> They have made sure that Borland will think
> twice before they ever release
[snip]
I should think Borland would. Or atleast they will remove the back doors in their source before releasing it. But of course this was an isolated incedent. I think Borland have done more damage than any of the firebird team could have possibly done by having a back door in their software. Whats the bet that sys admins around the globe are considering ditching all Borland software because it can no longer be considered trustworthy.
Your attempts to hack a Borland database show more you lack of knowledge than any real proof that the security hole wasn't all that bad. I think I would trust the knowledge of people who actually hack the software over a poster on slashdot with a very large user id (=> recently registered) and having only posted once (=> someone from Borland with sour graphs?).
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
They got hit by two or three format string bugs. For a while it said only one local root hack in 2 years and then that bit disappeared.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
>it was no known root exploits in the default
>install for three years.
Which makes a big difference. If you are running something that is vulnerable then you must have enabled it. When you see the advisory (if you aren't reading advisories then you're vulnerable on account of being a bit dim) you will probably recognise the service as one you had to turn on and patch it.
In a non-secure by default system, the vulnerability may go un-noticed because you never enabled the service yourself.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
I'm sure other people could think of more scenarios
can be found at InterBase Developer Initiative web site: www.interbase2000.org.
I've been taking advantage of it for the last 30 minutes!
WAY TO GO SLASHDOT! WOOHOO!
*snicker*
-=-
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
The problem is, are the higher level, "safe" language compilers/interpreters "safe" themselves? Or do they contain their own share of bugs that could lead to irregular behaviour and exploits? What would be a good idea is to write a compiler/interpreter for a safe language such as Scheme, CL, ML, or Haskell and audit it to the extreme. There are probably several efforts (such as a compiler written in ML that is provably correct), but I only know of one that depends so heavily on the compiler (Vapour, but its a bit more than just a compiler). As for Java, well Java doesn't have closures, so in my eyes it is crap.
Those who do not know the past are doomed to reimplement it, poorly.
It's an age-old debate. Older than the computer. Some people feel that it's just torture to tell a terminally ill patient that they're about to die. Others welcome the opportunity to say goodbye to friends and spend the their retirement money.
`ø,,ø!
Free Software: Like love, it grows best when given away.
I've seen a steady increase on probes to TCP port 3050 the last few days, so obviously some mailing lits have had the info available for a while. There seems to already be at least one skiddy kit just to probe for this vulnerability.
It will be interesting to see what various inquiries produce as to why this was put into the code, and why it existed for years in open source before being discovered.
Off to modify some router ACLs to log and drop...
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
Have a closer look ;-)
The code is intialised to the variables in the .h file, and when the server starts up it repaces them with random data using chars with ascii values 1-255
So every time the server starts up you get a different random password.
I've posted somewhere else, a bit about how this was done just prior to christmas, to fix the problem, and not introduce any unknowns.
A more perminant fix will be applied, we found it when we were doing a review of the security
There are problems, but in Firebird we have several people who do crypto/PKI things for their day job and we were doing a security review, that in part explains how we've found these. It also places us in a good position to fix these things. As far as Borland are concerned, they seem to be ignoring us,
They wouldn't tell Jim they were working on a patch for prior versions of InterBase, so he felt compelled to write his own.
But for now it's a good time to keep your Firebird/InterBase server locked behind a firewall
Cheers
Mark O'Donohue
--
Your database needs YOU!
http://firebird.sourceforge.net
Huh? This strikes me as a rather semantic argument. It all depends on how you define the word "problem". In any event, I'd say (and I think most others would agree to) that the most pressing security concern of any product consumer, be it open source or closed, is the effective security of the product. How the problem came to be is not nearly as relevant to the consumer as IF and WHEN it becomes known. Notice: This is not the same thing as saying that just because a problem is unknown at some point in time that it is irrelevant...as long as there is an (actual) risk it is relevant. However, it is equally stupid to somehow imply that any closed source product with any backdoor (no matter WHEN or IF it is discovered) is somehow, necessarily, more problematic for everyone then an Open Source product with a zillion "accidental" security flaws that are discovered haphazardly in great number.
Put simply, I'd rather face the risk of ONE developer knowing a backdoor (or bug or flaw) exists than face a zillion hackers armed with many different exploits on the comparable open source product long before. One might argue this empirically: the percentage of highly exposed interbase dbs that were hacked versus the somewhat equivelent MySQL database (which, incidentally, has seen it's fair share of security problems).
All of this, however, is entirely besides my original point. The point is that the poster I was replying to, and indeed a great deal of open source dogma, says that such backdoors are impossible to hide for an extended period of time in a popular Open Source project. I simply assert that: If security flaws can lay dormant for years as the result of improper coding in popular Open Source products, then an honest to god backdoor can certainly be hidden in there by an intelligent coder with equal or greater success, even if it isn't trigged by something as trivial as "MY VOICE IS MY PASSWORD".
It really makes you wonder, when something like this has thusfar escaped the relatively large community of InterBase users: what is hiding in the software that we acquire in binary-only form?
I fully expect that somewhere, in a corporation's database, is the tacit knowledge that I wear brightly colored underpants each and every second Thursday of the month... };-)
"I know - let's make Quake...AGAIN! They just might be stupid enough to buy it..." (overheard at id)
Try http://www.acm.org/classics/sep95/
It is the "pretty" version.
****** WE hold these Truths to be self-evident, that all Men are created equal, that they are endowed by their Cre
I'd sugest that if you want to download the source to the "active" opensource InterBase project.
I'd try here
http://sourceforge.net/projects/firebird.
This is the Firebird - daughter of interbase project. All of the community changes happen here, and we have 30 odd registered developers and occasionalyl bump into the top 10 projects on sourceforge.
Of course since as one of those developers, Im probably biased ;-).
Cheers
Mark O'Donohue
--
Your database needs YOU!
http://firebird.sourceforge.net
... is the backdoors you dont know about, that exist in much of the software out there.
:)
maybe the governments that fear closed-source OS'es have a point after all
This is part of the patch to fix the problem. the orignal code was not as clear.
There is a lot of code, and a lot of it is old.
It generates thousands of warnings, and has lots of cute #defines
It was released without the proper build procedures, and it has (and there is still) an effort underway to make the build easy and crossplatform
Since we get no help from Borland and they are basically trying to ignore us. For instance an attempt to release a document called "Interbase Engine Internals" a 1991 document for public use was met with a legal threat to sue from Borland (and it still isn't released). The user documentation for InterBase 6.0 which has work contributed by Borland and others, still hasn't seen the light of day, since Borland wont even talk about settling the ownsership/release problem.
In all of these things, a security audit was one on the list, and we were pretty much starting out when we found this problem.
It's interesting that most of the engineers within Borland (most now former engineers, and some even on the Firebird team) didn't know about these problems.
I have other concerns as well (forinstance the default interbase install is to run as root user, that does not have to be the case and should not be) these all need to be addressed.
we have other issues that need to be solved but these are ones was we did expect to find.
BTW: Did you check out the problems with the file qatest.c. Which has been less widely reported.
What would you think of a QA department that insisted you place a routine into a production release of your product that lets any user delete the current database or crash your server at will.;-).
Cheers
Mark O'Donohue
--
Your database needs YOU!
http://firebird.sourceforge.net
I can't say I'm glad to hear of something like this, but at the same time it does strengthen our argument that open source *is* more secure.
Spin that.
I have a woman and money. Life is good.
It says the backdoor exists in the open source version they released. Which is probably how it was discovered. So they put a backdoor account in there, forgot about it, decided to open-source their product, and .. oops.
Guess that'll teach companies a lesson about open-sourcing your products: go through and take out all your backdoors first!
--- Where's my X.400 protocol decoder?
Well, thanks for elaborating my second paragraph ;-)
All opinions are my own - until criticized
However, that's not only evil nastyness, the day might come where a company blesses a db manufacturer for implementing a backdoor, just after both dba's got run over by the same truck.
When I was an MIS director, I had all the critical passwords written down on separate, sealed envelopes with my signature on them and put in a safe deposit box which could only be opened by the VP of finance -- specifically to guard against the event that the key sysadmins and/or I should come to an untimely end.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Joshua5?
I want to delete my account but Slashdot doesn't allow it.
On the contrary, it's VERY decent of them not to tamper with the code before releasing it. That way people can more easily learn about the problem and implements whatever fix they want.
In my experience, it is harder to analyse a twenty LoC C program working at the assembler level than a 20kLoC C program at source level. (Yes, I've done this.)
:^)
Also, it is possible for not only the compiler to have obfuscated backdoors, but also the debugger, decompiler and code-dump utility. Hell, if you monkey around with the OS enough, you can create a file which contains code that cannot be viewed using any tool but which can execute and contain any backdoor you care to name. Of course, that's a scenario only for the paranoid, and it would be very difficult to exploit in any systematic way too. You would also be able to use 'cat' to strip the offending code...
"Little does he know, but there is no 'I' in 'Idiot'!"
Firstly I didn't say that you just had to read the code from cover to cover, I said that you had to read the code from cover to cover and you do. Secondly, terribly competent programmers write buffer overflows all the time and if only incompetent people write buffer overflows then this whole project was written by morons because it is full of em. Very good programmers write buffer overflows all the time because it is not in their job description to be a security expert. That's not to say that I think they shouldn't know what a buffer overflow is and how to avoid it but I hardly think it relfects on their coding skill. Frankly if I have the choice between a developer who can code to specification, on time, on budget and with efficency and yet doesn't know strcpy from strncpy and a guy who cant code for crap but can find a flaw in 10 minutes and write the sploit in 5 but cant code a damn, I'll take the good coder, cause that's who I hired. Fallability is about ignorance but I dont think ignorance of security issues makes you a bad programmer.
How we know is more important than what we know.
True, but I guess my point is that many companies go the open source route to save money. Since they don't want to spend the extra cash to check source themselves, they'll be more likely to go with the better known programs, in this case, MySQL or Postgres, assuming they haven't gone to a commercial product. If trust is lost in Open Source, when could happen is less corporate support for the lesser known projects (and Interbase isn't so unknown), leaving only a few to survive.
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?
How we know is more important than what we know.
Good to see you have a copy of 'Teach Yourself C in Two Minutes'. Every VBScripter should have one :))
Err - **whose** web site? Firebird's web site is at http://firebird.sourceforge.net.
The InterBase2000 site is the InterBase community website.
Hey, I only suggest Java because it is similar enough to C to possibly make my dreams come true in the short term. I don't like it either. =)
You'll probably be interested to know that we DO have compilers which generate provably safe code. One piece of the puzzle is TAL: Type safe assembly language. Another is TILT: A type-preserving ML compiler. They've also got projects on compiling safe-c, proof carrying code for transmitting this stuff over the network (without sandboxing), etc. The technology is almost there.
And while I agree with you that the compiler is an important source of more bugs... wouldn't it be nice to plug up holes on the programmer end (since compiler bugs right now also introduce more non-safety) while we wait for this stuff?
that's right. Could should be "the simplest thing that could possibly work". That is the goal of a programmer and this aversion that people have to reading code is just scary. I can't believe they sit down and start hacking away at it without even reading it first.
How we know is more important than what we know.
This is certainly a smart thing to do, like a disaster recovery plan, which is actually tested, clearly labeled and externaly stored backups, computer rooms, that don't look like my apartement at the age of 19 (the hifi equipment, specifically), etc...
Reality is quite different, unfortunately.
Nevermind, I still don't think that backdoors are necessarily bad, if they are not hidden and if they are not exploitable by every yoyo walking through cubicle land.
Admittedly, two big ifs...
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Borland was able to keep this secret for years, or the developers of borland.
Since the source was released, it's obvious that the developers that added the backdoor have already left borland, since it wasn't removed, and the other developers haven't noticed that there is a backdoor.
So, If it can go undetected even if the whole world has access to the source. So might this indicate that there is a very certain possibility that the crackers who broke into MS DID backdoor the source?
At first it may seem like opening up the source has made the software insecure, since anyone could have found this hole ages ago and exploited it. However, by realistic reasoning this will actually make the software MORE secure since the hole will be plugged. Who knows who the author of the backdoor has shared his information to? Just another example of the benefits of using Open Source software, gratis or licensed. Nothing more to see here, move on..
- Steeltoe
http://www.debunkingskeptics.com/
My management did this as part of the Y2K business recovery plan (BRP) along with all kinds of inventories, alternate routing plans etc.
But they haven't been touched since Jan 1, 2000 so they no longer reflect reality. I wonder how many other companies have left their Y2K disaster planning to bit rot on shelves somewhere. After spending millions of dollars creating these BRP documents, they are wasting all this work when it could be easily maintained for other contigencies.
Some extra info (mostly non-technical, but detailing the discovery and subsequent Borland (non)response) is available at the Interbase Developer Iniative.
BTW, it seems that, as usual, they were not very concerned.
Actually, the last time I checked out openBSD, they claimed "no remote root hacks in 3 years; no local root hacks in 2 years"
;-)
That was sometime early summer. (??) I guess they had a local root vuln since then
Perhaps you could post 95 theses to the back door and get ex-communicated.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Since it is a #DEFINE, could it be inside #IFDEF DEBUGS? And why the heck is it a #DEFINE in the C code? I would think that all users would be stored and read from the database? I'm just wandering...
J.
For security reasons, the patch is available only as a binary and you will be required to register for this download.
Nice, eh?
M.
Aparently it's a genuine quote, published in this interview in the The Register .
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
Here in Texas, you can get a quarter-pound of some decent Mexican weed for ~$150-$225 U.S. per quarter pound. Gold is ~$265 an ounce, so if you can't get weed for less than $265 U.S. an ounce you obviously are paying entirely too much for it!!! (unless it is some bad-ass Hydroponic weed
I am pro-legalization of drugs. In theory your
Anyway, aren't pot-heads are supposed to be MELLOW?
--
You think being a MIB is all voodoo mind control? You should see the paperwork!
A man who wants nothing is invincible
why not:
Open Sesame
That would seem more appropiate
Bolke.
- In Memoriam: Jeroen de Bruin (1972-2004), bye bro
Sometimes, having a backdoor is not a bad thing(tm).
Imagine a scenario where you administer 100's of users which, somehow, administer at the same time their own space. (virtual mail domains for example).
A backdoor password is usefull to administer all and every mail domain. But, only if the channel is secured somehow...I would not use a backdoor password while sending passwords as plain text over the network...
Well, get used to bad english and don't be ashamed....looks like everybody speaks bad english in slashdot but at the end, they get communicated....jajaja
Sorry, but I disagree. I would even call that a BIG PROBLEM
I have come to a conclusion that one useless man is a shame, two is a law firm, and three or more is a congress -J Adams
If you check the source repositories, you'll find that there are at least three different versions of the backdoor username and password. One in firebird, one in the sourceforge interbase project, and one in the interbase source you can get off conxion's mirror of the source. And from the comments in the code, it appears there the backdoor user and password orginally had yet a fourth version (likely the original), although the comment has been changed in the sourceforge repositories. It takes about 3 minutes to find this backdoor, even if you've never seen the interbase sourcecode, and have only a passing familiarity with C. You get the source, find the central authentication file (grep the tree for password and make a guess based on the file names. pwd.c is pretty obvious). Then you simply open the file and look at the authentication routine, where its as plain as day. Any somewhat-above-average kiddie that cared to look could have been trashing databases (and getting root, most installations I've seen have IB running as root) for about a year now.
.. BS score 100/100.
The source has been open since July 25 2000. It has (I forget how many) million lines of code and no tree documentation.
You find out not because the company chose to tell you but because it was discovered in an Open Source security review and reported to the CERT Coordination Center.
Be grateful for the thousand eyes, public watchdog bodies that are concerned about Internet security and software development that craves perfection and openness without the impediment of commercial expediency.
I wish I could count how many Script Kiddies are working there heads of now on that backdoor.
Bolke.
- In Memoriam: Jeroen de Bruin (1972-2004), bye bro
If he bothered to click on the link he would see that it is about Australian drug laws, where only two types of pot are sold. Leaf and skunk. Leaf is lame and costs next to nuffin. Skunk is hardcore shit and costs a small fortune. I dont smoke pot, I just support the end of prohibition.
How we know is more important than what we know.
Most of the old school software houses have compiled in some back door or provided an hidden way to get access to users systems all over the years. In my opinion it's common practice. They just love to have this kind of control/power over consumers.
Loosing this kind of control is one among other things that make industry afraid of going open...
Makes me wonder how many back doors are there in other Borland's products, specially those intended for app development. Is it possible that a back door could be compiled into every Delphi/C++ builder/Jbuilder app ever written, or at least the apps compiled with Standard versions, which don't provide the source of the libs?
Has something like that ever happened before?
I'm too lazy to discover this myself. Anybody remember when the source was released?
--
Fuck the system? Nah, you might catch something.
This is why Microsoft wont open source windows.
"The secret of success is to know something nobody else knows." -Aristotle Onassis
Why pick on Loki games? Is that a fact based paranoia, or a personal vendetta?
What would Loki have to gain by getting into the average gamer/Linux users machine? and compare that with what Borland could gain by leaving a backdoor in it's product. Access to large corporate/organization databases, the support call from the frenzied admin who lost or forgot the admin password, etc...
Leaving a backdoor in Mechwarrior or Quake3 just doesn't make any sense...
3dlan.com --> Monthly lan parties in Western NY
So much for that story. "They" will find it!!
Sig (appended to the end of comments I post, 54 chars)
The thing that always surprises me; whenever someone finds a backdoor or other major security flaw in any Open Source (much like the weak key generation in pgp a while back), especially when the problem was there for a long time is how surprised people are that it was missed in an Open Source environment. There was even an earlier comment that Open Source makes this sort of thing impossible. What makes Open Source superior is that we can all scrutinize the code... but how many do. How many times does some auditor skip past some obfusicated section rather than puzzle over it for hours. I think anyone who ran this software has to assume some responsibility once it became OpenSource.. once you have the code your lack of diligence is as much to blame as the authors stupidity. Especially in a large company.. If you don't have the kind of programmers who can vet code then hire one|them.
Of course, any computer is only as secure as its administrator.
Many people seem surprised that it took so long to find the backdoor. Their logic is that since it is opensource and has countless eyes looking at it, then it should have been noticed much sooner. What they don't realize is that a project like this is usually in the range of hundreds of thousands to millions of lines of code and when a developer goes into a project of that scale, he/she does not read everything, but only enough to learn the overall structure of the program, then zeroes in on sections that have been identified to need work or may contain known bugs.
If anyone truly believes that things like this should be found faster, they should try reading through this amount of code. When their heads stop spinning they will probably have a change of heart.
However, that's not only evil nastyness, the day might come where a company blesses a db manufacturer for implementing a backdoor, just after both dba's got run over by the same truck.
Ok, CHANGE_ON_INSTALL (Oracle) or a NULL password on MSSQLServer and Sybase are not backdoors. They are fairly well documented defaults and the problem lies with companies hiring incompetent dba's. Hell, you have this nice point-a-cklicka interface. Why in earth should we spend 120k on a dba?
What is a backdoor on one db however, or could be considered one, is the ability to start the database server while generating a new password for one of the dba's they scratched out from under that bus. However, this can't be done by Joe Dork in accounting, you need either root or access to the startup files. This is not officially documented, but I tought it numerous times in the respective dba class?
Is this a security risk ? Potentially, of course. Is it necessary ? Well, you decide. If there is no way in the world (safe for a hex editor, and that's no fun on a 500gig database) to access your corporate data it's a god send. If you're the security officer of a company, it's probably worse then cockroaches in your cake.
Backdoors can have absolutely legit reasons, but they have to have a certain level of protection. And keeping it a "secret" is not an appropriate protection.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
it reminds me of the movie wargames. maybe it was matthew broderick who found this backdoor also.
From what I understand, this security hole have been there for years. This was (mostly) harmless as long as the machines were not connected to a global network (well, it could be used to do a lot of harm, but for someone that already have access to the network where the database run. Anyone technically given access to the internal network of a company can do a lot of harm, anyway. Most of internal security is security-thought-obscurity. Hence, when you know how to search...)
What most guys don't realise is that many many closed-source software that currently run on many computers contains such backdoors, generally implanted to ease remote maintenance (and cut down costs). I, for one, would be _very_ surprised if there was no such backdoor in the various incantations of proprietary operating systems.
Cheers,
--fred
1 reply beneath your current threshold.
It's certainly a good arguement against using anything that comes as binary on a machine that needs to be secure. My machine doesn't need to be secure, though.
Says who? The problem with closed source is that they often are not inspected at all. It is not an Urban Legend that there exists one MS product that was used as a prime example of how not to organize a programming task. We now know it as MS Word :-(
>Remember, they produce commercial software, people are going to pay for this stuff. That's why backdoors in Microsoft products do not exist.
Hmm...
Remember, Borland/Inprise produced Interbase as commercial software, people had to pay for this stuff. And still the backdoor existed.
If it had been open source from the start, the programmers would have thought twice about including a hard-coded backdoor - and probably decided against it. And if not, people would have known it and closed it themselves.
A backdoor you know about can be closed (usually). A backdoor you don't know is impossible to close...
penI'yIn 'ej pechep
The Roach
Hopefully not...
There's another line in there that indicates they didn't just switch passwords:
When she later spoke with someone from InterBase R & D, the "fix" he described was merely a change to a string - no fix at all.
M.
I totally disagree, you might not change them, but for those of us that do, it matters. All my Oracle default passwords are changed, if I had an Interbase DB, I couldn't change/disable the backdoor! That is bad! What is worst, is that with default passwords you are at least aware of it, whereas backdoor you are not, and people can use it against you. Before the source to interbase was released, can you tell me that someone didn't string the binary and found that?
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
4 words for you:
"Netscape Engineers are weenies"
Now, what was that about proper management team?
You can download the surce Here
According to the page it was registered at Source Forge on 2000-Jan-28 15:37
--
Why pay for drugs when you can get Linux for free ?
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
We would like to believe that, but how do we know that they didn't? Perhaps they just missed out on this? Lots of shops clean up their code before release, didn't you remember when taco released slashdot's code? or when ID releases code? Perhaps the coder who cleaned it up saw it, but left it to get back to Borland? or perhaps see how long it will sit in the opensource community before it is picked up by anyone.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
Besides, who is stupid enough to run games as root anyway?
This is why you shouldn't even trust your own computers, with only you logged in!
Interesting things to do with a windows computer: run it behind a strong firewall and see just how many products you can download try to talk back to their "homes".
- Paul
See, this is why we need something like capabilities or that NSA Linux, so we can safely run untrusted (ie, any) program and give it only the exact permissions it needs. That's no help with a database, but it'll keep a bad game out of your personal finance data...
(I suppose *real* paranoids could run their Loki games under User-Mode Linux, eh?)
Lots of people here are apparently surprised that it took so long for this backdoor to be found. I thought I'd try to present an explanation.
1. Interbase wasn't officially released under an open source license until last summer. I at least, did not spend any serious time with it until the license was correct.
2. The open source interbase got off to a very slow start. Here's why:
- Borland didn't release all the tools required to build and test interbase code.
- Many of the original developers had left Borland, meaning that there was a shortage of mentors for new developers.
- Borland yanked startup funding at the last minute from the group that was going to take over the management of the code base, causing many to question interbase's future.
- Documentation of the code base is still unfinished.
- The codebase is large and complex.
Independent interbase builds (firebird on sourceforge) didn't start happening until very recently. In my mind they found this bug faster than I would have expected.
-OT
Sounds like security through obscurity to me. Maybe they didn't fix it at all but just changed the password. Perhaps comparing the patched binary to the original would reveal that.
WARNING: When looking into the back orifice, DO NOT ignite a flame. Spontaneous combustion may result.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Uh. First off, that doesn't mean open source products are any more secure. Second, many of them do not involve buffer overflows at all, but rather race conditions, poor checking of passwords, fundamentally flawed security architecture, terribly stupid flaws (remember phf?), etc. Third, more difficult for whom and in what way?
It would take a hacker a significant amount of time to discover a properly hidden and hardcoded backdoor in a closed source product. Notice how many years it took ANYONE to discover this. That is "difficult", or rather time consuming for the hacker. You might say it's easy to reproduce, but that's true for literally hundreds of Open Source security flaws. Once a hacker discovers a means and releases an exploit, the work is done. It doesn't matter to the hax0r, aka script kiddy, if exploit.c sends "LET ME IN BACKDOOR" or a bunch of machine code to the target host. Furthermore, it's quite easy to test for the existence (or at least the probable existence) of a security flaw via improper bounds checking. In other words, you just send a bunch of different programs extra long strings on various inputs until something crashes, then you simply do the work to make the exploit happen. Compare this with trying to find a well hidden backdoor in a closed source product, you either try to reverse engineer the binary or you can try brute force. In either case, it's much harder to detect.
So the question remains, easier for whom and how is that relevant? It's really not terribly relevant if you ask me. The question is how secure is YOUR product at the end of the day in YOUR environment for YOUR needs. If you start overgeneralizing by saying "Open Source is secure, Closed Source is not" then you're making a fundamental mistake. Rhetoric and dogma are not conducive to practical security.
> it'll keep a bad game out of your personal finance data...
Or (in my case) keep a good game out of my bad personal finance data...
Who's to say you're compiler doesn't have a bcak door? Just because you compile the code doesn't make it any more secure unless you _wrote_ the compiler yourself!
who's askin?
Loki can't GPL the games they put out, they are direct ports of closed source games. They have to sign contracts, NDA's and the like saying that when they license the source code, to do the port that they will not share it with others. If they only ported previously GPL'd games, you wouldn't get Myth, Sim City, Descent or the like. So you either accept that they are closed source, or you play the (mostly) crap games that you CAN get under the GPL.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
Or for back doors, what about the NSAKEY?
The best way to catch bugs and security holes is to code review when changes are made, not read the entire source afterward.
If code reviews were done when this code went in, it would have been picked up. Most source control managers have differencing tools to see what changed, and that is crucial when auditing security related code.
Quantum: in the true spirit of the new millenium (seeing how I have just booked my Lunar Holiday and the space suit is down the dry-cleaners), I appreciate your viewpoint and would like to aplogise if you thought I was attacking you!
... no need to differentiate us!
You're point as to pointing out that no-one had actually looked at the source of the patch was an extremely valid and important one.
As to distinguishing between network and software security, well I started as a coder and moved into whole architectures, so I'm a generic security consultant
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.
How we know is more important than what we know.
In order to stop a compiler from adding any thing to your program is to compile the compiler from source code. BUT! The first compiler also can add this feather to your new compiler as well. The solution is to have a basic compiler written in Assembler. This way you do not need to start with a binary compiler that you can know with 100% is clean of any bad things. This is very important in the Open Source world because most programs are known and not modified very much if at all before compiled. Compile GCC with a good simple Compiler written in Assembler and You can then be 100% certain that your programs do not any unwanted added feathers like back doors unless you your self write them in.