Slashdot Mirror

Also, good luck finding the back doors if they were written by contestants in the underhanded code contest.

That's only a problem with crap software. Fortunately, C is always readable, and you always know what it's doing.

You also have to be competent enough to evaluate the security vulnerabilities of said source code.

Case in point.

It's when people DON'T provide source that you should be suspicious, or when you can't get close to their source providing their binary.

Reading does not mean understanding. It takes more effort to hide malice in an open source project, but it is still very possible. It becomes geometrically easier to hide hostile behavior as the size of the source code increases, or even if there is simply no planning to the structure of the system (like OpenSSL).

On the other hand, http://underhanded.xcott.com/

Some of the solutions people came up with to hide malicious code are quite elegant.

The process that removes problems induced by errors (stupidity) ought to be good enough catch the ones induced by malice as well.

Maybe, maybe not. The technical aspects of designing stable code and understanding exploitable code do have a lot of overlap, but there are many cases relevant to one and rarely considered by the other. Someone with intent to add a vulnerability will not just change a login line to add 'or password=DaBears', although I suddenly wonder how long that change would stay in a repository before being caught.

Combined with the above, these two assumptions (risk of exposure, looking for compromises) is sufficient to take the approach that the code is not likely compromised on purpose. This is not to say, that there are no risks, just that they aren't likely to be intentional.

Either that, or the backdoors are much more sophisticated and designed to look like genuine errors once discovered.
Probably would look much more like something out of the "Underhanded C Code Contest" than an explicit "If (NSA_flags == ture) then send_to(NSA, data);"

In theory, someone with half a clue would notice that putting backdoors has 2 very strong disadvantages:
- a bug exploitable by your guys is a bug exploitable by Russian/Chinese/etc. a hidden backdoor in software used by US civilians also makes them at risk of being vulnerable to the enemy
- once starting to get discovered, it will ruin the market: US products will get considered as NOT trust-worthy, and foreign customers are going to avoid them. Lowering the secuirty of US software is a commercial suicide (as already witnessed back in the "56bits max" era in DES encryption), and should be avoided at all cost.
In practice, I doubt that such consideration would ever stop the NSA doing its work. It might be also likely that they booby trop the shit out of every single domestic commercial software while knowning 100% sure that foreign agencies too are abusing the backdoors that the NSA put there for themselves.

What's easier to spot... a backdoor in software where you can see the source, or one where you can't?

Try it for yourself. The difference is equivalent to the difference in the odds of winning a lottery with or without buying a ticket.

To make the claim that linux has been never been intentionally weakened in security, you need to know that every single security vulnerability in Linux (to take one example) was due to carelessness, not intended action.

Certainly - some classes of backdoor are trivially obvious 'if(sourceip==NSA)' - but others can be subtle logic errors.

You mean like this attempt in 2003?

Personally, I'm not longer all that impressed by the IOCCC. Don't get me wrong, some of the code submitted there shows utterly insane levels of skill. However, the above is an excellent example of a good submission for the Underhanded C Contest, which is an excellent teaching tool for discovering exploits as well as for learning about subtle bugs that may drive you utterly mad trying to find.

I'm suprised that no one mentioned the Underhanded C Contest
http://underhanded.xcott.com/

Quoting their web site:
"The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil. "

And the sneaky code doesn't even have to be obfuscated. It could be underhanded. And that's harder to review than closed source software, which one could just consider to be very well obfuscated.

Really, I don't think you're going to find holes by looking at the source code. You're going to find holes by poking and prodding at the binaries after they're compiled. Debugging. But at least with the source code available, you can plug the holes and trace the exploits back to their contributor.

c) You're relying on the fact the auditors can actually identify the fault in the code. Given that a backdoor can be inserted as easily as putting a = sign where an == sign belongs and given the quality of entries in the Underhanded C Contest I would say that not nearly every coder is competent at identifying nefarious code. Not to mention the number of exploitable bugs that exist at large.
d) You're assuming the source code matches the binaries, and while people may be routinely looking at your code, the vast majority of projects not built from source are NOT decompiled and checked against their source to see if someone hasn't tainted the binaries.

Having auditable code does not magically make you safe.

I guess that then we need to automatize those tasks, because we are NOT given enough eyeballs. We need power tools to help us.

First, I must say that even though compilers could be tainted, they lack intelligence to detect all cases in which they should decide to insert malicious code. A new kind of attack must follow introduction of a new target, not the other way around. If compiler is compromised, it probably carries a hit list of known constructs to look for. Therefore, they could be fooled and trapped.

For c) we need some sort of c-lint program to which we can add new heuristic rules of finding underhanded or vulnerable code, after we learn of their ways.
For d) there should be a program which decompiles binaries and compares that with allegedly matching source code, on semantic level (does this do the same as that?).

What has been snuck past linus and the other code reviewers. Honestly Linus needs to do a call for people to comb through and look specifically for sneaky things. It's not hard to make something look innocent in C but instead it does evil. http://www.ioccc.org/ for example. or more scary... http://underhanded.xcott.com/

Linux needs a security team that is double checked by a team outside the USA so it can be the ONLY OS that can state, "Not compromised by the NSA"

http://underhanded.xcott.com/

It's amazing what some of these people come up with to hide malicious code using seemingly honest coding mistakes that are hard to spot. And I'm sure the NSA can do even better than them. Certainly in a huge, complex piece of code like the Linux kernel. And how many people really inspect that code anyway?

Have a look at some of the code from the 'Underhanded C Contest' at http://underhanded.xcott.com/ where people write code that looks straightforward and nice and clear but contains deliberate evil bugs. I think that should remove any complacency and the NSA has a lot of money to spend on people posing as developers never mind the ones they stick onto standards bodies.

*If* such a mechanism was coded in, the nature of open source would mean it would be found by others.

The nature of open source means it MAY be found by others. Sure you have a higher chance and an audit trail but you're making multiple assumptions here:

a) The code will be audited, and while this is true for the Linux kernel it may not be true for *insert small open source project with few developers here*.
b) You're relying on the audit to look in the right place, i.e. it's one thing to compromise the Linux network stack, and quite another to compromise *insert convoluted X11 protocol no one has touched in years here*.
c) You're relying on the fact the auditors can actually identify the fault in the code. Given that a backdoor can be inserted as easily as putting a = sign where an == sign belongs and given the quality of entries in the Underhanded C Contest I would say that not nearly every coder is competent at identifying nefarious code. Not to mention the number of exploitable bugs that exist at large.
d) You're assuming the source code matches the binaries, and while people may be routinely looking at your code, the vast majority of projects not built from source are NOT decompiled and checked against their source to see if someone hasn't tainted the binaries.

Having auditable code does not magically make you safe.

That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.

He probably means something more along the lines of The Underhanded C Contest. For a quick example, here's the one from earlier in this comment section about a kernel backdoor that was attempted to be inserted:

            if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
                        retval = -EINVAL;

Sure if you only look at these two lines, you may easily see it's an assignment and not a test. Shoved into a few other thousand lines, though, it's probably going to evade visual scrutiny. This is also a direct consequence of the language involved, a logic error in an algorithm can be far more subtle.

A previous year's Underhanded C Contest finalist made a 'programming mistake' in an RC4 implementation that would slowly weaken the stream until it was only plaintext. A visual inspection and even a quick execution test would not show the problem.

That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.

He probably means something more along the lines of The Underhanded C Contest. For a quick example, here's the one from earlier in this comment section about a kernel backdoor that was attempted to be inserted:

            if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
                        retval = -EINVAL;

Sure if you only look at these two lines, you may easily see it's an assignment and not a test. Shoved into a few other thousand lines, though, it's probably going to evade visual scrutiny. This is also a direct consequence of the language involved, a logic error in an algorithm can be far more subtle.

A previous year's Underhanded C Contest finalist made a 'programming mistake' in an RC4 implementation that would slowly weaken the stream until it was only plaintext. A visual inspection and even a quick execution test would not show the problem.

Wasn't this found to be a hoax? Or not so so much as a backdoor, but your everyday common bug, that could lead to a hack?

http://blog.erratasec.com/2012/05/bogus-story-no-chinese-backdoor-in.html

Because the idea of discuising a back door as a bug has never been come up with before?

I just found the key quote:

The researchers identified a “Factory Key” (passcode) that was designed - in by Microsemi for production and failure analysis use

In other words, there was a backdoor, but it wasn't put there by the Chinese fab, but at the explicit decision of a USA based company. Whether you believe them that it was for their own use or for use by others is another question.

Intel engineer here. We get the same shit. Everyone thinks we fill the chips with back doors when we don't.

Aircraft instrument software designer here.

I once took some time to consider what it would take to hack the software I was writing. IOW, if I wanted to put a backdoor or vulnerability that could knock a plane out of the sky, how would I do it?

I did some research into underhanded C and such like, and tried to come up with a way that I could do it. (And came up empty - unlikely with so many eyes looking in-depth at the final product.)

Question for you: Have you ever done that? Have you looked at your dev process and thought in detail how you might do it?

An open code (with reviewers on it) means that is at least hard that a backdoor sneaks in.

Hard for some perhaps. See The Underhanded C Contest for examples of hiding in plain sight.

Much more relevant to this discussion is the underhanded C contest where backdoors much be introduced in innocuous-looking C code. There's an art to it.

For true malice there's also The Underhanded C Contest.

From their home page: "The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil."

The actual challenge this year is to write an evil C file that can calculate the "Bacon degree" separation of two users in a database that keeps track of their friends, with 0 meaning no linkage at all, 1 meaning they're directly BFF, 2 meaning that they have a BFF in common. In other words, the path length on the graph of friends. Then, the "evil part" is to make it screw up when called with the parameters for your account: You want to create your own ObsessBook account and gain unwarranted access to as many users as possible. To this end, your code should work normally almost all the time, but for some unseen reason it should return incorrectly low DERPCON values when called with your account as an argument. As the contractor, you have access to the ObsessBook database, so you can assign your data structure whatever fields you want in order to trigger the bug.

This reminded me of The Underhanded C Contest -- where the goal is to introduce malicious-acting but innocent-looking bugs that, even upon discovery as bugs, could be passed of as programming errors and not intentional backdoors. This should be required reading for anyone reading potentially-hostile code that's trying to pass an audit.

Surely Huawei has a large enough networking codebase to put enough of these in that Oz won't find them, and even if they do find them all -- how do you prove that a bug with an unintended leak/security concern was malicious?

Very clever stuff but I always found The Underhanded C Contest much more interesting. Sadly the last one of those was in 2009. I'd love to see that return.

As anyone familiar with the underhanded code contest knows, it's possible to create code that looks fine, easily passes reviews from people even who are on the lookout for back doors, yet still contains back doors.

It's essentially impossible to prove that your equipment is NOT backdoored, unless you designed and built it in-house and believe that your own engineering staff is trustworthy (its own problem, when there is a history of governments buying off employees within companies that have access to critical data and processes).

Let's not turn this into some weird racial thing. There are very good reasons to be skeptical of letting non-allied governments, or indeed any external governments, near major national communications hardware - especially if it's likely to find use for defense or other strategic purposes.

One of the single biggest problems with things like this is the hardware side of things: how do you make sure that the black-box hardware you're buying (and any silicon chip is exactly that, at least until you open it up and follow the traces and even then - see the Underhanded C Contest - for why "source code" is a poor metric for determining security in a lot of cases.

Letting a Chinese company install large orders of hardware into a national network is just idiotic. It may not be that much wiser letting a US company do it, but Australia is allied with the US whereas we still define national security policy by notionally assuming China to be a foe in some capacity.

Google pulled out of China precisely because they experience demands for surveillance and repeated efforts by suspect government sponsored hackers to invade the privacy of accounts. Letting companies from the same area install network hardware is madness.

Having a copy of the source provides only minimal protection. See for example the Underhanded C Code Contest.

It would be an almost trivial exercise to introduce a vulnerability into a code base that wouldn't be picked up easily by either human or mechanical inspection. Even if such a vulnerability was detected, the vendor could simply claim that it was a coding error, fix it, and get away with it unpunished. By adding a few dozen such vulnerabilities, the vendor could play this game for years without anyone ever being able to prove wrongdoing.

There's no hope of isolating the equipment or software from the Internet either, because the use-case here is a National Broadband Network, the whole point of which is to create a new public Internet backbone.

Have you ever heard of the Underhanded C Contest. You get points for making the code exhibit some kind of backdoor, extra points for the more it looks like it could've been an innocent mistake (for instance, code where using a less-than-or-equal-to operator instead of less-than operator actually opens up an obscure security hole, and it's a mistake programmers make all the time).

I recommend you look at some of the examples of winning entries. It's amazing what these people have come up with. No number of eyes will find it. Simply put, even if it's a popular open-source project, thousands of eyes are likely to miss a well-placed backdoor like these. And if anyone is capable of doing it, the NSA certainly is.

Still don't believe me? How about the OpenSSH PRNG flaw that went unnoticed for two years, despite being used in servers all over the world. It was due to someone removing what appeared to be a useless line of code, but that code was actually adding some necessary extra entropy to the random number generator. It might've been an accident, or malicious. But the point is it happened, and on a high-profile project.

It's the underhanded C contest.

Many of the image-processing solutions were very clever ways of hiding bugs in code. Some were more likely to pass a code review than others. Many of them would not really pass dedicated testing. The winning entry that you mention does character-substitution in an ASCII PPM file, replacing all digits with zeroes. If you look at the file in an image browser, it's actually redacted. If you look at the file in a text editor and have security in mind, you will immediately be very suspicious. The nice bit is that the code is very short and the error subtle enough that it's very easy to overlook the problem.

The IOCCC is cool, but the Underhanded C Contest was a lot more valuable.

The entries for the IOCCC can show a lot of cleverness, but nobody in their right mind would accept such code. The beauty of the Underhanded C ones is that the code looks reasonable, but does extremely undesirable things.

Come son, come. Please do realize that code can look innocent while doing malicious things. You know of what I speak.

For example: http://underhanded.xcott.com/

There. Examples, contests, code snippets and real life stuff. Go and learn some. I'll be so proud of you.

Lots of kisses.

Dad.

Not possible?

These guys beg to differ: http://underhanded.xcott.com/

Of course, it's much simpler to convince the users that they *want* their data to be sent to the servers than to try to hide it.

point is that people who opt to use some kind of UNIX as their primary machine are usually not technically clueless

That has not been my observation; the majority of Mac OS X users I know of do not know a lot about their computers, nor are they interested in learning. They purchased a system with Mac OS X because they heard that it was easy to use and would give them fewer headaches than a Windows system.

The second point is that most UNIX distros (including OS X) come with hundreds of tools to monitor the system, inspect binaries etc.

Tools which only the most experienced users can use to detect malware; even technically literate people may not be able to spot suspicious behavior.

Also, good chunk of software is downloaded as source and compiled and the localhost. This also gives you a chance to look at code directly.

Allow me to introduce you to my favorite programming contest:

http://underhanded.xcott.com/

But it's so easy to hide a backdoor in plain sight you might as well not called it plain sight.

http://underhanded.xcott.com/

It's possible to have code that looks and even functions innocently but does something nasty. You can bet this is the technique used. If discovered, it just looks like a regular vulnerability - a coding mistake.

It is not that difficult to detect the problems...

Maybe not for an experienced code reviewer who's examining 20 lines of code for an extremely simple security need. In the real world it takes extraordinary resources (talent, discipline, passion) at both the individual and organizational level to produce "logically" secure software. Even then, it usually takes academic/hacker security research to find subtle, indirect attacks that depend on power consumption, network behavior, and other such complexities [the SSH packet-timing vulnerability springs to mind here].

Every professional software developer can, at some point in their life, benefit from studying material similar to Meacham's vulnerability. Maybe you are so far beyond that level that you do not appreciate the Underhanded C Contest's educational potential. Pity that it's not better established, but maybe that will come in time.

"seasoned" code reviewers who can't understand what the program is supposed to do in the first place? You are overestimating your competence.

It's supposed to write a '0'! The sneaky bit is it writes extra zeroes depending on what is being "censored".

Good luck with a rewrite when your resulting program has better readability but doesn't even work.

See: http://underhanded.xcott.com/?p=8

The object of this year's contest: write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out

Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.

The removed pixels don't have to be perfectly reconstructable; if a very faint signal remains, that's often good enough for redacted document scans. Indeed, an attacker may know that a redacted block might be one of two words, and any tiny bit of leakage that helps her determine which is more likely is technically a valid attack. However, more points are given for greater pixel leakage.

And the PPM format: http://netpbm.sourceforge.net/doc/ppm.html

You obviously have not seen things like this http://underhanded.xcott.com/

I have just seen them, and they all fail simple shallow code review or code readability test.

As unlikely as it is that any backdoors have made it into OpenBSD, even an audit cannot conclusively prove that there are no backdoors in the code. Witness the Underhanded C Code Contest. The goal of the contest is to write a chunk of code that does something, well, underhanded that is difficult to detect even upon close examination of the code. The winners have been quite successful. Even with only 15-20 lines of code, it's a challenge to locate the underhandedness even when you know exactly what you're looking for. The phase "microscopic needle in a galactic hacksack" comes to mind when imagining the challenge of finding malicious code that may or may not even be there, in a code base thousands or millions of lines long.

Isn't that like someone just making another entrance to your house and then painting it over to match the brickwork..?

Check out the Underhanded C Contest. Sure, a patch containing, "if(packet_csum=SEKRUT_FBI_BACKD00R_P4KT) { /* d0 3v1Lz */ }" would get noticed pretty quickly. But good security is really subtle; it's probably difficult, but not impossible, to make proper-looking code that actually screws up in just the right places. The main problem is that anything that subtle is as likely to get broken accidentally as well.

Please pardon my likely sheer ignorance (or even misunderstanding) on this topic, but how is it possible for someone to code a backdoor into encryption software in an open source project..? I mean, wouldn't someone notice..?

Assuming other people are reviewing the code, there's still the possibility of subtle, deliberate bugs. A number of examples can be found in the Underhanded C Contest.

...can be made over something so obvious. OpenBSD's code has been screened again and again. If something was amiss somebody would have noticed it . . .

Yeah just look for the parts commented //super secret FBI backdoor, shhh!

You obviously have not seen things like this http://underhanded.xcott.com/

You dont realize how it is possible to hide evil code in front of someone's face..

http://underhanded.xcott.com/

go there and read, look at the winning and runner up entries... If you are a competent coder you can hide things right in front of someone and they will not spot it. It's scary as hell what some of these guys can do.

It'll be stuff like "The Underhanded C Contest": http://underhanded.xcott.com/?page_id=17

Or normal non-obfuscated RPG II:

http://en.wikipedia.org/wiki/RPG_II

The code obfuscation competitions won't be good examples - since obfuscated code looks hard to understand, which would make it more noticeable to auditors, or even "normal programmers" looking at the code.

It'll be stuff like "The Underhanded C Contest": http://underhanded.xcott.com/?page_id=17

Or this: http://www.debian.org/security/2008/dsa-1576
Or "accidentally" leave in a few exploitable buffer overflows or other "normal" bugs.

As for over reliance on "many eyes", just relying on it is over-reliance. The "many eyes" claim is not applicable when it comes to _security_ bugs.

There are many eyes, but they're all "watching TV". They'll notice if a bug crashes their DVR or causes image corruption, other than that no.

There are only very few skilled experienced eyes auditing the code, and not all of those are on the "defending" side.

And done wrong, even that is reversible.

i'm concerned about bugs, intentional or not, that would allow someone access to my voice calls or other personal data... how feasible are those situations when using one of these 3rd party mobile operating systems rather than the one supplied directly by the mobile vendor with the device?

You don't know it but what you are indirectly implying is that open source community developed systems could harbor more undisclosed vulnerabilities due to less peer review, either accidentally or, a via more disturbing proposition: that someone may masquerade as a coder in a community project to hide something in plain sight (certainly possible: http://underhanded.xcott.com/) obtaining sudden pwnership of thousands of phones (last I heard CyanogenMOD was on 30k Android phones now likely many more).

In all likelihood attacks against a vanilla carrier ROM on a Android handset may just not work against heavily modified aftermarket ROM. One would hope anyway. Hackers are also not going target individual ROM distributions, they'll go after mainstream devices. Any of these vulnerabilities in Android will be everyone's problem.

Still, I sold my iPhone 3G so some sucker can 'downgrade' that to iOS4 lag hell and I made a choice for an open source handset with a superior security model for a damn good reason.

It's a logistical impossibility for Apple to rigorously peer review every line of code that goes through their App store, which is why the false sense of security from a their strict walled garden is dangerous.

Android market has some protections, and Android's security model and code base is more robust anyway.

Oh and the Android open source community is fucking awesome.

Right. It gets worse, it's completely possible to hide malicious code in plain sight http://underhanded.xcott.com/?page_id=2. I doubt Apple analyze every single line of code, let alone rigorously review and test applications for malicious behavior. It's simply not logistically possible. I would go so far as to say they cannot actually test for malicious code or exploitable flaws on any reasonable level, that one has little grounds for excuse in assuming any iPhone app is 'safe' because it gets Apples stamp of approval.

If anything the walled garden vetting process is dangerous, it gives an enormous false sense of security to users, especially if it promises protection that is not only unfeasible but it demonstrably cannot give.

Give me the open source + Android security model any day. So far it's pretty good, and it will see honest attempts to improve rather than Apples denial and lies machine.

This then should be the contest for you!