|
|
Log in / Subscribe / Register

Security quotes of the week

To address this type of attacker, we present Oblivious DNS (ODNS), which is a new design of the DNS ecosystem that allows current DNS servers to remain unchanged and increases privacy for data in motion and at rest. In the ODNS system, both the client is modified with a local resolver, and there is a new authoritative name server for .odns. To prevent an eavesdropper from learning information, the DNS query must be encrypted; the client generates a request for www.foo.com, generates a session key k, encrypts the requested domain, and appends the TLD domain .odns, resulting in {www.foo.com}k.odns. The client forwards this, with the session key encrypted under the .odns authoritative server’s public key ({k}PK) in the “Additional Information” record of the DNS query to the recursive resolver, which then forwards it to the authoritative name server for .odns. The authoritative server decrypts the session key with his private key, and then subsequently decrypts the requested domain with the session key. The authoritative server then forwards the DNS request to the appropriate name server, acting as a recursive resolver. While the name servers see incoming DNS requests, they do not know which clients they are coming from; additionally, an eavesdropper cannot connect a client with her corresponding DNS queries.
Oblivious DNS project at Princeton

Up till now, writers of crypto and security software not only have to fight the bad guys. We also have to deal with compiler writers, who every so often dream up some new optimisation routine which spots the padding instructions that we put in to make our crypto algorithms run in constant time, or the tricks that we use to ensure that sensitive data will be zeroised when a function returns. All of a sudden some critical code is optimised away, your code is insecure, and you scramble to figure out how to outwit the compiler once more.

So while you’re fighting the enemy in front, the compiler writer is a subversive fifth column in your rear.

Ross Anderson

Last year, the Defcon hackers' conference sponsored [PDF] a Voting Village. Organizers collected 25 pieces of voting equipment, including voting machines and electronic poll books. By the end of the weekend, conference attendees had found ways to compromise every piece of test equipment: to load malicious software, compromise vote tallies and audit logs, or cause equipment to fail.

It's important to understand that these were not well-funded nation-state attackers. These were not even academics who had been studying the problem for weeks. These were bored hackers, with no experience with voting machines, playing around between parties one weekend.

Bruce Schneier

to post comments

Security quotes of the week

Posted Apr 26, 2018 6:13 UTC (Thu) by mjthayer (guest, #39183) [Link] (15 responses)

> All of a sudden some critical code is optimised away, your code is insecure, and you scramble to figure out how to outwit the compiler once more.

Surely the most reliable way to outwit the compiler's optimiser is simply to turn it off. It would be very nice to be able to mark areas of source code which should or should not be optimised, but failing that, splitting code which should and should not be optimised into separate source files should work for any reasonable compiler, and you even get fine-grained control over which optimisations you want.

Given that most code in most projects is not expected to be performance-critical, I always wonder anyway why people waste time and fossil fuel (and risk uncovering assumptions in their code they would rather not have known about) optimising it build after build.

Security quotes of the week

Posted Apr 26, 2018 6:29 UTC (Thu) by mjthayer (guest, #39183) [Link] (2 responses)

> Given that most code in most projects is not expected to be performance-critical, I always wonder anyway why people waste time and fossil fuel (and risk uncovering assumptions in their code they would rather not have known about) optimising it build after build.

Perhaps some day compilers will learn to detect code paths which will not benefit from optimisations and optimise them away...

Security quotes of the week

Posted Apr 26, 2018 7:08 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

> Perhaps some day compilers will learn to detect code paths which will not benefit from optimisations and optimise them away...

Maybe, but at the cost of making them slower still. In the mean time, programmers could be doing a decent work at this right now, if they just were aware of the problem.

Security quotes of the week

Posted Apr 26, 2018 7:35 UTC (Thu) by mjthayer (guest, #39183) [Link]

> Maybe, but at the cost of making them slower still. In the mean time, programmers could be doing a decent work at this right now, if they just were aware of the problem.

Quite agree there. I was just wondering whether making compilers learn when not to optimise might be more of a fun/challenging task for compiler writers than deciding which code to optimise or not for programmers, and therefore more likely to happen. Then again, optimising build time has become fashionable lately, so perhaps there is hope.

Security quotes of the week

Posted Apr 26, 2018 6:57 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Because it's easier to turn on the compiler's optimizer by default than it is to profile the code to know what is performance-critical.

Security quotes of the week

Posted Apr 26, 2018 11:41 UTC (Thu) by jwakely (guest, #60262) [Link] (1 responses)

> It would be very nice to be able to mark areas of source code which should or should not be optimised

GCC's optimize attribute allows that:

    int slow(int i, int j) __attribute__((noinline,optimize("0")));

Security quotes of the week

Posted May 3, 2018 20:37 UTC (Thu) by nix (subscriber, #2304) [Link]

... but of course this may not prevent the compiler biting you in the arse if you rely on undefined behaviour. Optimization isn't some special magic: it's just doing stuff during translation, and the compiler is quite within its rights to assume that the program is not invoking undefined behaviour in passes other than those that happen to be part of the optimizer. (And it does.)

People who assume that -O0 makes GCC into some sort of "translate the input into the output no matter what undefined stuff we do" machine are operating under a false assumption. No such magic machine exists (nor can it). It appears that what they actually want is a compiler that knows what undefined things they in particular are doing, and does the right thing in those cases. (Good luck with that.)

Can't always turn optimizers off

Posted Apr 26, 2018 11:42 UTC (Thu) by wittenberg (guest, #4473) [Link] (3 responses)

Even with optimization turned off, some compilers do some optimization anyway. It's really hard to find a way to get the compiler to do what you told it to do.

Can't always turn optimizers off

Posted Apr 26, 2018 12:29 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

Even if the compiler does what you told it to do, Spectre demonstrates that the CPU won't do what the compiler told it to do. Maybe we need to give up on the idea of implementing timing-attack-safe cryptographic primitives in software, and do it all in hardware instead.

Can't always turn optimizers off

Posted Apr 26, 2018 14:48 UTC (Thu) by mrshiny (guest, #4266) [Link] (1 responses)

"the CPU won't do what the compiler told it to" proves that you can't always do it in hardware either.

Can't always turn optimizers off

Posted Jun 7, 2018 1:34 UTC (Thu) by JanC_ (subscriber, #34940) [Link]

Especially as fixing the hardware is often not possible (or at least requires hardware vendor intervention).

Security quotes of the week

Posted Apr 26, 2018 17:03 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think the idea of not optimizing code isn't really sensible: when compiling C, there are a lot of choices you have to make that are potentially relevant to performance and there's no clear unoptimized answer. You can certainly tell the compiler not to try to make each path individually as fast as possible, but that just means it's going to produce code that's easy to generate, which still might not conform to your expectations about what's the same.

The right thing is probably to define a standard for uniform performance, and then mark your crypto code that way, and then compilers will do what you've told them you expect.

Compiler writer's views

Posted Apr 26, 2018 20:16 UTC (Thu) by wittenberg (guest, #4473) [Link] (3 responses)

For a loud (if not entirely enlightening) discussion, see the Bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
In which the compiler writers essentially tell the kernel developers: "tough"

Compiler writer's views

Posted Apr 26, 2018 22:39 UTC (Thu) by jschrod (subscriber, #1646) [Link] (2 responses)

Thanks for this pointer; that is really a scary thread.
I was a aware that too many applications demand -fwrapv nowadays, but didn't know why.

That bug discussion thread is reason to evaluate barring gcc usage in critical conditions.

Anybody can tell if the Clang developers are more reasonable if they receive that kind of problem report?

Compiler writer's views

Posted Apr 27, 2018 6:35 UTC (Fri) by mjthayer (guest, #39183) [Link]

Shouldn't undefined behaviour sanitiser make GCC warn about optimising things away like this?

Compiler writer's views

Posted May 3, 2018 20:40 UTC (Thu) by nix (subscriber, #2304) [Link]

I doubt it. As several people pointed out in that bug report, the complaint was about an optimization GCC has been doing since the *early 90s*, and they were demanding extremely impolitely that it get ripped out as if it were something that had been added the previous week, and ignoring the response that it just isn't as simple as that.

Oblivious DNS project

Posted Apr 26, 2018 20:41 UTC (Thu) by HenrikH (subscriber, #31152) [Link]

While this prevents small scale eavesdroppers from seeing your DNS requests this does little to stop the big players like NSA who since they control large enough portions of the net can use timing and length poisoning to connect the request from the client to the .odns resolver and the .odns resolver request to the authoritative server (they can already do this with TOR traffic).

Security quotes of the week

Posted Apr 26, 2018 20:56 UTC (Thu) by naptastic (guest, #60139) [Link]

> The client forwards this, with the session key encrypted under the .odns authoritative server’s public key ({k}PK) in the “Additional Information” record of the DNS query to the recursive resolver, which then forwards it to the authoritative name server for .odns. The authoritative server decrypts the session key with his private key, and then subsequently decrypts the requested domain with the session key. The authoritative server then forwards the DNS request to the appropriate name server, acting as a recursive resolver.

This seems like it could become a vector for a DNS reflection attack.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds