Linked by Thom Holwerda on Tue 14th Dec 2010 23:55 UTC, submitted by Oliver
OpenBSD Okay, this is potentially very big news that really needs all the exposure it can get. OpenBSD's Theo de Raadt has received an email in which it was revealed to him that ten years ago, the FBI paid several open source developers to implement hidden backdoors in OpenBSD's IPSEC stack. De Raadt decided to publish the email for all to see, so that the code in question can be reviewed. Insane stuff.
Thread beginning with comment 453696
To view parent comment, click here.
To read all comments associated with this story, please click here.
google_ninja
Member since:
2006-02-05

And you obviously don't know what you are talking about if you think that code with a logic issue is easier to detect then code that does something completely different then it should.

Reply Parent Score: 3

TheGZeus Member since:
2010-05-19

"On two concert I'm should collective photo, but such small, fat, bald-headed technologist be insane".

I'm not going to reply to something vague and nonsensical with anything but the same.

Reply Parent Score: 1

TheGZeus Member since:
2010-05-19

Checked your website to see what your first language is.

It seems to be English, and you normally write it well.

As such, I see this as obfuscation of any possible point.

That, combined with an anti-scientology post (I'm no fan of scientology, just to be clear) and it's fairly clear you know the Rules of the Internet, and probably don't talk about /b/ or talk about /b/. (not a typo, to anyone who hasn't read that list of insane rules)

Reply Parent Score: 2

google_ninja Member since:
2006-02-05

it was a glib response to a glib answer, thats it. My point (which I still stand by) is that it is much easier to find something that does something completely different then its intent, then something that does whats intended, but the author didn't think of one of the cases that ends up happening to real world people. The person who originally wrote it didn't manage to think of it, it usually means you could read it and not catch it either.

On the other hand, when you read a method that says that it is (for example) reading a file, and instead uploads your passwd file to a remote website, it is hard to miss what it is doing. There are ways you can obfuscate it, but mostly that just makes things unreadable. Blobs of unreadable code should be targets for refactoring, which would expose the issue.

The only way that they would even be comparable is if the back door wasn't written as a back door, but more as a vulnerability (i.e. an intensional bug). In that case, I wouldn't say it was easier or harder to find, it would be the same.

I think that is common sense, and anyone who knows enough to be able to understand the difference between a bug and a feature would be able to see how that is obvious. I don't think that it means that it disproves the whole "many eyes make for shallow bugs" thing, but I do think the assertion that bugs are easier to find then code that says it does one thing but actually does another to be, to be frank, downright moronic.

So, I thought I was banging out a quick, sort of funny response to a dumb comment. If you want to talk about this I'm totally fine with that since you don't seem to be an idiot (which is why I am taking the time to write this out) I wasn't really trying to troll, but at the same time I wasn't seriously trying to debate a point either.

Reply Parent Score: 2

Valhalla Member since:
2006-01-24

And you obviously don't know what you are talking about if you think that code with a logic issue is easier to detect then code that does something completely different then it should.

Seriously, how long have you been programming and at what level? I programmed professionally for 8+ years (assembly, c, c++, perl, python). You can hide malicious code in logic issues aswell as using other techniques. For some examples (that I think you should be able to follow):

http://underhanded.xcott.com/?page_id=17

And this was in the crypto framework, which is quite advanced stuff and the mail mentioned key-leaking mechanisms. And no, it's not going to be any function call in the middle of the code called 'leak_keys()', I thought you were just trolling but it seems you are most likely very incompetent.

Edited 2010-12-15 15:58 UTC

Reply Parent Score: 3

google_ninja Member since:
2006-02-05

7 years, but only high level application languages (ruby/perl/lisp/a bit of smalltalk/c#/java), never done systems stuff.

I can sort of muddle through C++ (never really had interest or job opertunities), but something like "if(x > rx * 3 && x <= (rx + rwidth) * 3 && y > ry && y < ry + rheight)" I wouldn't consider to be that great in any language, and a prime candidate for refactoring. You may not catch it in a security audit, but you will if you are trying to maintain quality in your code base.

In any case, I will concede that a deliberate obfuscation like what you linked to is of equal difficulty to find then a bug in similarly gnarly code. What I don't buy is that it is significantly harder to find, which was the implication of the person I was responding to.

wrt the whole incompetence remark we're talking about skimming an article and banging something out while drinking my coffee getting ready to start the day. I probably would have said the same thing as the previous paragraph in a great deal less of a condescending way if I had fully read the article and thought through what it probably was referring to. I would call that "introducing a vulnerability", a back door to me sounds more like I am expecting something in a specific format, but if I get it in another format just return true. That sort of misunderstanding would definitely be incompetence if I were in the security industry, but that is very very far from what I do.

Reply Parent Score: 2

ichi Member since:
2007-03-06

And you obviously don't know what you are talking about if you think that code with a logic issue is easier to detect then code that does something completely different then it should.


If you were to put a backdoor in some program you wouldn't insert a "backdoor code", which could be easily spotted, but place a concealed bug that you can exploit later. A bug inside a piece of code that other than that does exactly what it's supposed to do.

As such, in the event it was found, it would be indistinguishable from any other bug, and because it's deliberately concealed it'd be harder to find.

Which leads to believe that maybe, just maybe, someone could actually have fixed that backdoor already (if it's true that it was placed to begin with). If some dev had found it he wouldn't have gone "OMG A BACKDOOR!!!" but just fix it the same as with any other bug.

Reply Parent Score: 3