5 ms·

I just love reading post-optimisation machine code.

by ChoHag 10y ago

tptacek 10y ago
Pretty much everyone who's job involves using IDA Pro does this every day.
- ChoHag 10y ago
  People who use disassemblers for a living enjoy reading machine code? Holy! Fuck! Just call me Watson, Sherlock!
  - verbify 10y ago
    If people were that diligent, heartbleed would never have happened.
    - ChoHag 10y ago
      Yes. They're not.
stouset 10y ago
The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.
- Retr0spectrum 10y ago
  But do they? It's a slightly dangerous assumption to make. If everyone assumes that, nobody will bother to check at all.
- pbhjpbhj 10y ago
  So if they implemented a small extra procedure to copy text and send on a side-channel when a flag was set externally, if such a thing was done then this would be obvious to many people despite it being closed source? Aren't these apps developed modularly? Or indeed if it were a patch that could be initiated as forced update at will from the server-side, again that would be clear to "people" based on the client side binary? These are the ways I imagine I'd snoop on supposed end-to-end encrypted communication channels; there's probably something much cleverer, but again, we're saying that can be detected easily? Genuine questions, not a programmer, not familiar with the state-of-the-art of reading machine code/interpreting network traffic, nor indeed with which watchdogs are guarding against abuse by the TLAs.
  - tptacek 10y ago
    That's not really what "side channel" means. You mean "covert channel", a related but different concept.
    - WhitneyLand 10y ago
      The bigger point he's making is that your comment "Anyone who can read a control flow graph" can be taken to mean everything is fine here when it's really not. Its not hard to imagine how WA could be compromised without anyone knowing for many years.
      - tptacek 10y ago
        I don't understand what you are trying to say here, sorry.
    - pbhjpbhj 10y ago
      I was thinking something like using the SMS channel which, IIUC, was originally for carrying solely control information and ergo is a side-channel; more in the telecoms sense than the crypto sense. Yes, perhaps "covert channel" would be better. Do you have any response to the substantive point or just quibbles on the semantics.
- eps 10y ago
  A couple of concrete names from this "plenty" would be a good start... That is, those who read WhatsApp disassembly and did thourough enough review to warrant with sufficient confidence not raising any flags. It would also help to know which specific build the were looking at.
- robryk 10y ago
  You assume that the binary you are using is one those people have already seen. This need not be the case: a rollout might have started hours ago and you might have been one of the first few to get the new version.
- verbify 10y ago
  We had access to openssl code, and yet heartbleed happened.
  - niftich 10y ago
    It's about incentives. The heartbleed bug was present in the code for almost two full years before someone who discovered it exercised responsible disclosure. It's possible that others have noticed it before this, but it's highly likely that the only people looking were security researchers, power users (like Google, the ones who first reported it to the authors), or actors looking to exploit it for their own agenda. As it stands, average people (or average developers) have little incentive to go trawling through the existing body of open source code, mostly because they probably have better things to do with their time. In the commercial world, bug bounties attempt to skew the incentives to encourage the 'more eyes' part of the axiom 'given enough eyeballs, all bugs are shallow'.
    - verbify 10y ago
      Granted Heartbleed was only exploitable for a few years, but Shellshock was available since '89 And I'm pretty sure bug bounties would apply to shellshock and heartbleed as long as you can find a company with a bounty program that also used openssl or could be exploited via bash.
  - petre 10y ago
    Bugs were also discovered in Cisco IOS and Juniper JunOS that led to security compromises and a leaked NSA rootkit. At least open source code cand be audited by independent security experts, forked, rewritten and fixed (see LibreSSL).
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- nickpsecurity 10y ago
  They didn't for vast majority of problems in open or closed source software. It was black hats or security researchers digging around with intent to use, sell, or fix it. A tiny, tiny subset of people who can code in or read assembly. What you and other assembly verification supporters are proposing is an assembly version of the many eyeballs hypothesis. The idea that many people that are qualified could see it means they thoroughly analyzed it in a way that implied actual security results. I see little to no evidence of that. Actually, I see the opposite where malware hits binary systems in many ways that were easily preventable at source or assembly. That assumption means I don't trust the claim that assembly being verifiable means that it was likely verified. More like stockpiled into a 0-day collection. You also can't trust something to be correct, reliable, and secure with assembly or binary alone. If you could, high-assurance field would be all over that. Instead, the evidence indicated the source... esp if requirements were encoded as formal policy... had more information to work with to analyze potential compromises and information leaks. A lot gets lost in producing assembly. So, they instead analyze source for correctness in all states of execution for various properties then verify that assembly does same thing with some proof supplied to evaluators and/or customers. Much more trustworthy. Also almost non-existent for proprietary or FOSS software.

I just love reading post-optimisation machine code.

by ChoHag 10y ago

I just love reading post-optimisation machine code.

tptacek 10y ago

Pretty much everyone who's job involves using IDA Pro does this every day.

ChoHag 10y ago
People who use disassemblers for a living enjoy reading machine code? Holy! Fuck! Just call me Watson, Sherlock!
- verbify 10y ago
  If people were that diligent, heartbleed would never have happened.
  - ChoHag 10y ago
    Yes. They're not.

stouset 10y ago

The point was you don't, but plenty of people do. And those people haven't sounded the alarm on any red flags.

Retr0spectrum 10y ago
But do they? It's a slightly dangerous assumption to make. If everyone assumes that, nobody will bother to check at all.
pbhjpbhj 10y ago
So if they implemented a small extra procedure to copy text and send on a side-channel when a flag was set externally, if such a thing was done then this would be obvious to many people despite it being closed source? Aren't these apps developed modularly? Or indeed if it were a patch that could be initiated as forced update at will from the server-side, again that would be clear to "people" based on the client side binary? These are the ways I imagine I'd snoop on supposed end-to-end encrypted communication channels; there's probably something much cleverer, but again, we're saying that can be detected easily? Genuine questions, not a programmer, not familiar with the state-of-the-art of reading machine code/interpreting network traffic, nor indeed with which watchdogs are guarding against abuse by the TLAs.
- tptacek 10y ago
  That's not really what "side channel" means. You mean "covert channel", a related but different concept.
  - WhitneyLand 10y ago
    The bigger point he's making is that your comment "Anyone who can read a control flow graph" can be taken to mean everything is fine here when it's really not. Its not hard to imagine how WA could be compromised without anyone knowing for many years.
    - tptacek 10y ago
      I don't understand what you are trying to say here, sorry.
  - pbhjpbhj 10y ago
    I was thinking something like using the SMS channel which, IIUC, was originally for carrying solely control information and ergo is a side-channel; more in the telecoms sense than the crypto sense. Yes, perhaps "covert channel" would be better. Do you have any response to the substantive point or just quibbles on the semantics.
eps 10y ago
A couple of concrete names from this "plenty" would be a good start... That is, those who read WhatsApp disassembly and did thourough enough review to warrant with sufficient confidence not raising any flags. It would also help to know which specific build the were looking at.
robryk 10y ago
You assume that the binary you are using is one those people have already seen. This need not be the case: a rollout might have started hours ago and you might have been one of the first few to get the new version.
verbify 10y ago
We had access to openssl code, and yet heartbleed happened.
- niftich 10y ago
  It's about incentives. The heartbleed bug was present in the code for almost two full years before someone who discovered it exercised responsible disclosure. It's possible that others have noticed it before this, but it's highly likely that the only people looking were security researchers, power users (like Google, the ones who first reported it to the authors), or actors looking to exploit it for their own agenda. As it stands, average people (or average developers) have little incentive to go trawling through the existing body of open source code, mostly because they probably have better things to do with their time. In the commercial world, bug bounties attempt to skew the incentives to encourage the 'more eyes' part of the axiom 'given enough eyeballs, all bugs are shallow'.
  - verbify 10y ago
    Granted Heartbleed was only exploitable for a few years, but Shellshock was available since '89 And I'm pretty sure bug bounties would apply to shellshock and heartbleed as long as you can find a company with a bounty program that also used openssl or could be exploited via bash.
- petre 10y ago
  Bugs were also discovered in Cisco IOS and Juniper JunOS that led to security compromises and a leaked NSA rootkit. At least open source code cand be audited by independent security experts, forked, rewritten and fixed (see LibreSSL).
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
nickpsecurity 10y ago
They didn't for vast majority of problems in open or closed source software. It was black hats or security researchers digging around with intent to use, sell, or fix it. A tiny, tiny subset of people who can code in or read assembly. What you and other assembly verification supporters are proposing is an assembly version of the many eyeballs hypothesis. The idea that many people that are qualified could see it means they thoroughly analyzed it in a way that implied actual security results. I see little to no evidence of that. Actually, I see the opposite where malware hits binary systems in many ways that were easily preventable at source or assembly. That assumption means I don't trust the claim that assembly being verifiable means that it was likely verified. More like stockpiled into a 0-day collection. You also can't trust something to be correct, reliable, and secure with assembly or binary alone. If you could, high-assurance field would be all over that. Instead, the evidence indicated the source... esp if requirements were encoded as formal policy... had more information to work with to analyze potential compromises and information leaks. A lot gets lost in producing assembly. So, they instead analyze source for correctness in all states of execution for various properties then verify that assembly does same thing with some proof supplied to evaluators and/or customers. Much more trustworthy. Also almost non-existent for proprietary or FOSS software.