4 ms·

There has been some more recent work on this lately: https://www.dfrws.org/2016eu/proceedings/DFRWS-EU-2016-7.pdf https://www.dfrws.org/2016eu/proceedings/DFRW

by moyix 10y ago

There has been some more recent work on this lately: https://www.dfrws.org/2016eu/proceedings/DFRWS-EU-2016-7.pdf https://www.dfrws.org/2016eu/proceedings/DFRWS-EU-2016-7.pdf Essentially, with newer RAM (DDR3), the location things end up on the physical chip is scrambled to improve reliability: > Storage of bit streams which are strongly biased towards zero or one can lead to a multitude of practical problems: Modification of data within such a biased bit stream can lead to comparatively high peak currents when bits are toggled. These current spikes cause problems in electronic systems such as stronger electromagnetic emission and decreased reliability. In contrast, when streams without DC-bias are used, the current when working with those storage semiconductors is, on average, half of the expected maximum. So once you image the RAM you have to figure out the scrambling and undo it. Related: https://github.com/IAIK/DRAMA https://github.com/IAIK/DRAMA

nickpsecurity 10y ago
I didn't know DDR3 RAM was scrambled. Thanks for the link & tip. Analog scramblers of the past were defeated in a number of simple and clever ways. Most security engineers stopped trusting scrambling as it almost always fails. A useful obfuscation at best on top of genuine encryption and authentication in RAM as in my other comment. No surprise we have another one on breakers' resumes in the RAM area. Note: Nice shortcut link to the blog and research on it. LAVA is still on my backlog to check out although some itch in me suggests it has potential in high-assurance for testing tools, mechanisms for recovery-oriented architectures, or even teams with simulated subversion. Just haven't had time so far after work and looking at preventative stuff.
- moyix 10y ago
  Thanks! I'll be writing follow-up posts on the technical details and evaluation of LAVA as well. It's a really cool problem and I do hope that it can actually make bug-finding software better.
  - nickpsecurity 10y ago
    So, without digging into paper, it basically is about creating many test-cases to assess strengths and weaknesses of static analysis tools that should theoretically have found those injected bugs? As in previous comment, that could be a whole field of research in itself if it's not already. I'm not just talking about common case of injecting to test static analysis. Here's a few that pop into my mind as I run through old Orange Book and EAL lifecycle: 1. Inject flaws into formal specification of problem. Knowledge-based methods might do that for modifications in domain representing slip-ups of experts. Semantic methods might modify specs directly to flip a logical property. Preferably one similar to it to increase odds that they overlook it. 2. Formal policy of safety or security. This is a policy, type system, info flow labels, access control matrix... any of that. The injections would deliberately weaken the policy. This would combine templates that ensure common flaws got represented plus truly random ones. Lean more toward templates here as opponents will want to create things that break policy in catastrophic ways. That likely, but not certainly, means they'll focus on specific areas of policy for mods. 3. Formal verification. Similar to above or code-level tests but for intermediate forms or verification conditions. Maybe for proof tactics too if someone is trying to design a prover that doesn't get lost for too long. I think a simple time-out with trace log would suffice for that, though. 4. Code is the next part. You people largely have it covered in isolation. However, it must map to specs or requirements in high-assurance products. So, the mappings could be screwed up where code is tweaked to mis-match the spec similar to how specs are tweaked above. Also, the Design-by-Contract or other invariants might be modified to mislead an evaluator like SPARK Examiner or Astree Analyzer. If it supports it, the compiler instructions or pragma's might be modified to make compiler inadvertently break the code. 5. Testing. There's already a lot of work on this one where compilers, analyzers, tests, and/or fuzzers are mixed. I'll leave them to it as only basics are really needed for high-assurance. Other benefits or methods are still debated. 6. Effects of optimizations on source to object translation. Starts with equivalence checking ability. From there, different optimizations are used to try to break safety/security/correctness properties of the code with tool attempting detection. Goal of injector is to prevent that. Eventually, a corpus would be generated here of software fragments, transformation, and result that could tell us more via machine learning techniques. That's true of above in general but SSA etc is low level & small. 7. Covert channel analysis. Step most "secure" software misses although mainstream rediscovering it slowly as "side channels." Mainly focus on storage, timing, and resource exhaustion channels. Create tools to find the connections automatically in software either statically or dynamically with a test suite in progress. Inject covert channels all over the place. See what it finds. 8. Type systems. They're usually eyeballed or analyzed with formal methods. Often abstractly. I'd like to see above code- and formal-level injection combined to produce and test possible failures of executable, formal spec of type system and/or implementations of it. I bet it would find something. So, there's what's off top of my head as I apply my mental framework for high-assurance security onto the abstract of your LAVA tool. Much potential for research and results if this grows into its own field. All I ask if you or one of your PhD's turns this into real papers is credit for contributing the idea to do so. :) Regardless, what do you think of these? Are other people doing them? Are they novel? Which you see most bang for buck? Far as I can tell & based on current market share, biggest impact in order are static analysis, compiler optimizations, type systems, covert channels to stop memory leaks, and improved formal policies to support type systems and design-by-contract. The rest possibly useful but less so. Note: The short-cut link on your Twitter to your blog was hilariously named. If it was intentional.
- hatsunearu 10y ago
  scrambling != encryption scrambling is done in a lot of systems, especially in telecom to condition the signal to have some special signals processing property (reducing DC level, changing spectrum shape, etc)

by moyix 10y ago

nickpsecurity 10y ago

I didn't know DDR3 RAM was scrambled. Thanks for the link & tip. Analog scramblers of the past were defeated in a number of simple and clever ways. Most security engineers stopped trusting scrambling as it almost always fails. A useful obfuscation at best on top of genuine encryption and authentication in RAM as in my other comment. No surprise we have another one on breakers' resumes in the RAM area. Note: Nice shortcut link to the blog and research on it. LAVA is still on my backlog to check out although some itch in me suggests it has potential in high-assurance for testing tools, mechanisms for recovery-oriented architectures, or even teams with simulated subversion. Just haven't had time so far after work and looking at preventative stuff.

moyix 10y ago
Thanks! I'll be writing follow-up posts on the technical details and evaluation of LAVA as well. It's a really cool problem and I do hope that it can actually make bug-finding software better.
- nickpsecurity 10y ago
  So, without digging into paper, it basically is about creating many test-cases to assess strengths and weaknesses of static analysis tools that should theoretically have found those injected bugs? As in previous comment, that could be a whole field of research in itself if it's not already. I'm not just talking about common case of injecting to test static analysis. Here's a few that pop into my mind as I run through old Orange Book and EAL lifecycle: 1. Inject flaws into formal specification of problem. Knowledge-based methods might do that for modifications in domain representing slip-ups of experts. Semantic methods might modify specs directly to flip a logical property. Preferably one similar to it to increase odds that they overlook it. 2. Formal policy of safety or security. This is a policy, type system, info flow labels, access control matrix... any of that. The injections would deliberately weaken the policy. This would combine templates that ensure common flaws got represented plus truly random ones. Lean more toward templates here as opponents will want to create things that break policy in catastrophic ways. That likely, but not certainly, means they'll focus on specific areas of policy for mods. 3. Formal verification. Similar to above or code-level tests but for intermediate forms or verification conditions. Maybe for proof tactics too if someone is trying to design a prover that doesn't get lost for too long. I think a simple time-out with trace log would suffice for that, though. 4. Code is the next part. You people largely have it covered in isolation. However, it must map to specs or requirements in high-assurance products. So, the mappings could be screwed up where code is tweaked to mis-match the spec similar to how specs are tweaked above. Also, the Design-by-Contract or other invariants might be modified to mislead an evaluator like SPARK Examiner or Astree Analyzer. If it supports it, the compiler instructions or pragma's might be modified to make compiler inadvertently break the code. 5. Testing. There's already a lot of work on this one where compilers, analyzers, tests, and/or fuzzers are mixed. I'll leave them to it as only basics are really needed for high-assurance. Other benefits or methods are still debated. 6. Effects of optimizations on source to object translation. Starts with equivalence checking ability. From there, different optimizations are used to try to break safety/security/correctness properties of the code with tool attempting detection. Goal of injector is to prevent that. Eventually, a corpus would be generated here of software fragments, transformation, and result that could tell us more via machine learning techniques. That's true of above in general but SSA etc is low level & small. 7. Covert channel analysis. Step most "secure" software misses although mainstream rediscovering it slowly as "side channels." Mainly focus on storage, timing, and resource exhaustion channels. Create tools to find the connections automatically in software either statically or dynamically with a test suite in progress. Inject covert channels all over the place. See what it finds. 8. Type systems. They're usually eyeballed or analyzed with formal methods. Often abstractly. I'd like to see above code- and formal-level injection combined to produce and test possible failures of executable, formal spec of type system and/or implementations of it. I bet it would find something. So, there's what's off top of my head as I apply my mental framework for high-assurance security onto the abstract of your LAVA tool. Much potential for research and results if this grows into its own field. All I ask if you or one of your PhD's turns this into real papers is credit for contributing the idea to do so. :) Regardless, what do you think of these? Are other people doing them? Are they novel? Which you see most bang for buck? Far as I can tell & based on current market share, biggest impact in order are static analysis, compiler optimizations, type systems, covert channels to stop memory leaks, and improved formal policies to support type systems and design-by-contract. The rest possibly useful but less so. Note: The short-cut link on your Twitter to your blog was hilariously named. If it was intentional.
hatsunearu 10y ago
scrambling != encryption scrambling is done in a lot of systems, especially in telecom to condition the signal to have some special signals processing property (reducing DC level, changing spectrum shape, etc)