Slashdot Mirror

What you say is superficially reasonable and my work the first time around. Once it is known what flavor/distro is used in these voting machines, APTs will insert hard to detect flaws to be exploited.

It is quite possible to intentionally introduce an exploitable bug without it looking like sabotage.

It doesn’t even have to be visible in the original source code.

There was a whole contest, revolving around getting backdoors in under the radar: The Underhanded C Contest (The official perfectly innocent web page for law-abiding good guys)

And you can bet this is serious business for any spying agency on the planet. (Would you ignore it, if you were a spying agency?)

Ignore comments. Comments lie. Code never lies.

Are you familiar with The Underhanded C contest? Code does lie.

I think the main difference is that in open source it'd take some extraordinary trick to create a backdoor or unofficial feature for any particular group or organization.

No it does not.
All it takes is for the malicious individual to have slightly more skill than the evaluators of the specific function they added a vulnerability to.
Given how "thorough" open source code review is, a patient hostile actor will be able to get any vulnerability into the accept code of any project, the only issue is patience. In most cases, it doesn't require great coding skill, just the normal social-hacks that covert operatives are primarily trained in. Submit minor useful code changes while watching the bug tracker, fix one of the older bugs and see how the crowd responds. Mess up a fix on another old bug and see how the crowd responds. Just a few pokes to see what it takes to add truly malicious code.

The problem is that, in a complex enough code, you might not be able to tell even by looking at the source code.

Even simple programs can be unreadable.
And malicious intent isn't annouced with a comment of 'backdoor access here'.

Some bullshit about the product working only as intended. Hackers have been practicing obfuscated, "looks good but has a malicious side-channel" code since forever, and you'd be an utter dimwit (or vatnik!) to think that Mr. Kaspersky himself of the KGB's technical school doesn't know how to put these ideas into practice both programmatically AND socially.

But guess what? Even if Kaspersky has the most honest intentions in the world, which they don't, that still doesn't prevent SORM from capturing everything, or from the business from being coerced into providing those telemetry, binaries, and incidentally collected files. Same reason Russia wisely banned Pokemon GO from their country: it's not Niantic you worry about hoovering up all that telemetry and incidental data. It's the government who inspect and grab that traffic over top of them for mass collection and analysis to map out a country's signals with useful idiots.

This is neither good nor bad, but it's unquestionably different.

I beg to differ: it IS bad. Because when you read a+b, you have NO idea what may be happening. And this applies to ALL the operators. And the effect of the overloading can be completely different for various types. If participating in the underhanded C contest is not too hard, there's no need for an underhanded C++ contest because it'd be beating a dead horse.

however, linux users like to download and compile code...

when was the last time you really read through the linux kernel to make sure there wasn't an backdoor in it?
i supposed you can hope someone else has...isn't that the theory of open source security?

though what about that stupid library that you had to compile to make your GNU Widgets program work? now did you read that? it may not be as popular as something like the linux kernal, so does that really have enough eyes on it to ensure the NSA didn't insert some obfuscated malicious code?

links to the underhanded C or obfuscated C contests seems somewhat relevant here.

here is at least one example of the NSA trying to push a backdoor into software. this one may have been caught, but can we be sure we caught all of their attempts?

The ioccc is merely unreadable, it makes code really stand out. Instead, you want Underhanded C where code must be clear, appear good and pass code review.

The Underhanded C Contest provides plenty of ideas how a smart developer can subvert a system even in face of thorough code review.

And in Isis' case, if she was forced to make such a subversive commit, she could either:
  * refuse to be a traitor -- certain contempt of court
  * do it and get caught (immediately or after the fact) -- likely charge of contempt of court (they'd suspect she tipped the reviewers)
  * do it successfully -- and be a traitor of what we believe in

If people can make commits to Tor without too much scrutiny then the system isn't secure.

Malicious code doesn't have to be a simple "sendcopytoFBI(data)" function call. It can look a lot more innocent.

Check out the 2014 Underhanded C Contest for examples of code that looks normal but leaks information. How many of those would be caught - and if so, which ones could be excused as a simple programming mistake?

Cryptography is hard. Security is hard. Especially with Tor, due to its popularity and anonymity.

Further, the nature of open source code itself discourages the kinds of back-doors and underhanded application programming that most Linux users are familiar with in proprietary closed source operating systems.

I know you like to think that, but it's false.

The nature of open source code is advertised as preventing intentional back doors and vulnerabilities, but code review and organized testing are so rare that it makes no bloody difference. All these applicants are submitted as code, see how many you can parse as vulnerabilities without checking the cheat sheets.

As it would be rather difficult to force someone to put an invisible government backdoor in an open source source project,

Assumption failure. Counterexample.

The hard part about adding a backdoor to any system is in limiting access conditions to avoid accidental discovery. Writing it in such a way that it doesn't use a simple "if user=MI6; goto backdoor;" is a relatively easy task. Despite the claims of certain language advocates, any programming language can be obfuscated so that a secondary functionality is hidden alongside the primary. In most languages, you can just put a comment next to the obfuscated section explaining "readability sacrificed for better performance on AMD CPUs" or something like that and no one will question it.

The The Underhanded C Contest is a nice practical example why having the source available doesn't mean that you easily can find and fix intentional bugs, even if you know that they are there.
At some point it is easier to just write your own in-house application.

Many people here just assume that everyone on slashdot knows this stuff, however I think a full explanation is worthwhile so I'll try to give it.

Software just doesn't work like that. If you do not have the full source code to the software you are trying to verify you really can't know what it does. Even if you do, there are techniques which will mislead experts almost every time. People do try to understand binaries, e.g. in anti-virus companies, however those people may spend weeks or months and basically what they try to do is re-create the source code from manual careful analysis of the binary. Needless to say, this is far to expensive for any of the app stores to do.

In order to bypass something like an app store check, you just need a way to make sure your bad functions aren't active or visible when Apple accepts the app. Check the time and don't activate for two months after you submit the app. Download a logo. Only activate if it's colored red. When Apple tests the app it does nothing bad. When the user runs it later it does bad things. What is there for Apple to test?

This year's underhanded C coding challenge deals with nuclear warhead identification: http://www.underhanded-c.org/_...

The Underhanded C Contest would be a better place for this. And actually; I would enjoy seeing that contest.

Go look at some of the winners from previous years. Some of the solutions are on such a diabolical level that they might take days or weeks to fully track down and understand and are so convoluted that no one could possibly think it was intentional.

Last year's winner is a rather good example.