4 ms·

> And how did you screw up length x width x 4? There’s a million ways to screw that up. People botch SCM merges. People are hungover. People are distracted. Pe

> And how did you screw up length x width x 4? There’s a million ways to screw that up. People botch SCM merges. People are hungover. People are distracted. People are tired. People are heartbroken. People are going through divorces. People have parents dying. People forget numbers. People make copy-paste mistakes. All the time. > The sandboxed process doesn't have any way to exfiltrate data. You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped.

Dylan16807 3y ago
> People make copy-paste mistakes. All the time. But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. > You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped. There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerability. Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.
- Hackbraten 3y ago
  > But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. > Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes. The assumption was that the code tries to clean up the buffer immediately after use.
  - Dylan16807 3y ago
    > The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox. > The assumption was that the code tries to clean up the buffer immediately after use. Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. I think you're going for a situation where the sandboxed process can write to data in the host process outside the buffer? In a general sense I can imagine ways for that scenario to occur, but I can't figure out how you could get there via mmapping a buffer badly. A buffer mmap won't overlap anything else. If the mmap is too small then either process could read past the end, but would only see its own data (or a page fault).
    - Hackbraten 3y ago
      > Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing. If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sandboxed into the unsandboxed process and survive beyond the current transaction (because the code failed to zero the buffer correctly after use). In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. That data may not be very useful on its own, because it's still confined to the mmapped buffer. But it's now relatively well protected from reuse (until the next decoding task arrives). That's plenty of time to do shenanigans. For example, you can combine it with an (unrelated) stack buffer overflow that may exist in the unsandboxed process, harmless on its own but more powerful if combined with an attacker-controlled gadget in a known location.
      - Dylan16807 3y ago
        It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. > In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. But what is the arbitrary data going to be? 1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits needed. Also this requires the second dumb mistake of the coder going out of their way to mark the buffer as executable. 2. If it's data you want to exfiltrate, you could just gather that after you trigger your unrelated exploit. This is only useful if everything aligns to drop the private data you want in that specific section of memory, and then the buffer is reused, and then the private data is removed from everywhere else, and then you run an unrelated exploit to actually give you control. This is exceptionally niche. > harmless on its own Ha.
        Hackbraten 3y ago
        > It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions. Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance. > But what is the arbitrary data going to be? An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.

Dylan16807 3y ago

> People make copy-paste mistakes. All the time. But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. > You can abuse it to gain a (known-page-offset) write primitive in the other, non-sandboxed process to which the buffer is also mapped. There's no reason to have the memory mapped into both processes at once, and you can't exploit the bytes you write without a real vulnerability. Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes.

Hackbraten 3y ago
> But if you do that every image looks wrong and it's vanishingly unlikely to get into a release. The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. > Since it's a one-shot write into the buffer, if your intent is using it as an exploit step then you might as well encode an actual image with your exploit-assisting bytes. The assumption was that the code tries to clean up the buffer immediately after use.
- Dylan16807 3y ago
  > The code doesn't have to be wrong for every input. It may be wrong just for pathological cases that don't occur in the field unless specifically crafted. I could argue this more but it doesn't matter, that was just a little tangent, getting the size wrong will not let anything out of the sandbox. > The assumption was that the code tries to clean up the buffer immediately after use. Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. I think you're going for a situation where the sandboxed process can write to data in the host process outside the buffer? In a general sense I can imagine ways for that scenario to occur, but I can't figure out how you could get there via mmapping a buffer badly. A buffer mmap won't overlap anything else. If the mmap is too small then either process could read past the end, but would only see its own data (or a page fault).
  - Hackbraten 3y ago
    > Cleaning up would be removing the mmap. How are you going to exploit that? Your scenario is not very clear. If a buffer is going to be reused across calls, then cleaning after use is not the same thing as unmapping. One example for cleaning up a buffer after use would be zeroing. If there's a bug in the calculation for the amount of zeroing needed, then leftover attacker-controlled data can bleed back from the sandboxed into the unsandboxed process and survive beyond the current transaction (because the code failed to zero the buffer correctly after use). In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. That data may not be very useful on its own, because it's still confined to the mmapped buffer. But it's now relatively well protected from reuse (until the next decoding task arrives). That's plenty of time to do shenanigans. For example, you can combine it with an (unrelated) stack buffer overflow that may exist in the unsandboxed process, harmless on its own but more powerful if combined with an attacker-controlled gadget in a known location.
    - Dylan16807 3y ago
      It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. > In other words, the attacker can now write arbitrary data into the unsandboxed process's memory at a semi-known location (known page offset) inside the mapped buffer. But what is the arbitrary data going to be? 1. If it's gadgets with known lower bits, then you could put that into a plain-old image file, no decoder exploits needed. Also this requires the second dumb mistake of the coder going out of their way to mark the buffer as executable. 2. If it's data you want to exfiltrate, you could just gather that after you trigger your unrelated exploit. This is only useful if everything aligns to drop the private data you want in that specific section of memory, and then the buffer is reused, and then the private data is removed from everywhere else, and then you run an unrelated exploit to actually give you control. This is exceptionally niche. > harmless on its own Ha.
      - Hackbraten 3y ago
        > It's hard to see why the buffer wouldn't be per image. There's no reason to reuse that. Premature optimization is a thing. Most software developers are prone to it in one way or another. They may just assume a performance gain, design accordingly and move on. They may be working under a deadline tight enough so they never even consider checking their assumptions. Or maybe the developer has actually run the experiment and found that reusing the buffer does yield a few percent of extra performance. > But what is the arbitrary data going to be? An internal struct whose purpose is to control the behavior of some unrelated aspect in the unsandboxed process. The struct contains a couple of pointers and, if attacker-controlled, ends up giving them an arbitrary process memory read/write primitive.