SoylentNews is people
SoylentNews
from the one-bad-apple-spoils-the-whole-bunch dept.
Papas Fritas writes:
"Last October, Bruce Schneier speculated that the three characteristics of a good backdoor are a low chance of discovery, high deniability if discovered, and minimal conspiracy to implement. He now says that the critical iOS and OSX vulnerability that Apple patched last week meets these criteria, and could be an example of a deliberate change by a bad actor:
Look at the code. What caused the vulnerability is a single line of code: a second "goto fail;" statement. Since that statement isn't a conditional, it causes the whole procedure to terminate ... Was this done on purpose? I have no idea. But if I wanted to do something like this on purpose, this is exactly how I would do it.
He later added that 'if the Apple auditing system is any good, they will be able to trace this errant goto line to the specific login that made the change.'
Steve Bellovin, professor of Computer Science in Columbia University and Chief Technologist of the Federal Trade Commission, has another take on the vulnerability: 'It may have been an accident; If it was enemy action, it was fairly clumsy.'"
(Score: 3, Insightful) by FatPhil on Sunday March 02 2014, @12:37AM
Only an idiot would attempt to hide an exploit in open source software.
So there's no need to even check to see if there are such back doors.
Which makes it the best place to hide!
However, jesting aside, how this didn't flag a compiler diagnostic, I don't know. Or a coverity/purify warning about "unreachable code" or similar. This is dreadfully shoddy work from Apple, or whatever bottom of the barrel third-rate subcontractors were responsible from the code.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 4, Interesting) by frojack on Sunday March 02 2014, @01:13AM
I thought Bellovin blog was a better analysis.
I know all the compilers I use would have flagged the third IF as unreachable code.
However, most compiler will allow this with merely a warning, because sometimes programmers branch around stuff for testing purposes. (This is most competent programming shops doesn't allow any warnings in production code.)
Maybe Apple has lower standards, or maybe their compiler doesn't flag that kind of error.
No, you are mistaken. I've always had this sig.
(Score: 5, Informative) by mojo chan on Sunday March 02 2014, @11:31AM
GCC doesn't flag it, and neither do quite a few other compilers. The problem is that code being unreachable is only determined after optimization, and so different optimization levels can produce different results. That made the output of the check unstable, so it was disabled.
For example you might write some code that tests a variable and then executes one or two possible code paths (an IF statement). Without optimization the compiler will generate code to test the variable and branch. With extensive optimization the compiler might realize that there is no possible code path from main() through to this function that would cause the test to result in a true result and so optimize away the true result code path completely, removing the test and simply executing the false path.
Often it is desirable to disable or at least reduce the optimization level to minimum to aid debugging, because the assembler code produced with maximum optimization can be pretty much unreadable and break things like watching variables in the debugger because they get optimized down to multiple registers. It's really not an easy problem to solve.
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 2) by frojack on Sunday March 02 2014, @08:46PM
Wait, What?
An arbitrary GOTO, not subordinate to any conditional means that ALL subsequent lines up to the next label are unreachable. The second consecutive goto was totally unconditional.
You don't need optimization passes to detect that, it is basic compiler theory,
Hell, In the past have used code Editors built into IDEs that will detect that.
No, you are mistaken. I've always had this sig.
(Score: 2) by mojo chan on Sunday March 02 2014, @09:55PM
Sure, I was just stating why they disabled the feature. It wasn't reliable, the output changed based on the optimization level.
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 1) by MichaelDavidCrawford on Sunday March 02 2014, @04:05AM
I can no longer get into just about the most important email account I've ever had.
So I'm going to type all of my passwords into a text file, but that text file on a truecrypt volume, and then... ... WAIT FOR IT! ...
spraypaint that truecrypt's password on the side of a wall in one of Vancouver's rougher neighborhoods.
Yes I Have No Bananas. [gofundme.com]