6 ms·

So everyone downstream of weinzierl has to be aware that (1) the PDFs he hands them may be full of malware (2) have to use VMs (3) must open said malware-packed

So everyone downstream of weinzierl has to be aware that (1) the PDFs he hands them may be full of malware (2) have to use VMs (3) must open said malware-packed PDFs in a disposable VM (4) must strictly adhere to D-VM usage protocol.

dhimes 9y ago
Or weinzierl could print them and possibly rescan for further distribution.
- JulianMorrison 9y ago
  Convert to DjVu.
- blattimwind 9y ago
  Which is basically what Qubes "Convert to trusted PDF" does.
- nickpsecurity 9y ago
  My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. This might even be batched on simple hardware which itself has lower attack surface. Later on secure hardware like CHERI CPU albeit that can happen today if you have FPGA board and skills to run their HDL code. For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? ;) It might also be run back through similarly-deprivileged OCR to turn into a safer format. Gotta eyeball it if doing it that way. That said, there are fonts that work well with OCR that it might be converted to as part of image production if OCR is the goal in the first place. Could be a fun, little project teaching folks about a number of topics at once.
  - tptacek 9y ago
    Your "first solution" would be to take a de novo PDF implementation written in C, "compile it with something that makes it memory-safe", and then port it to an L4 microkernel. Maybe bust out some HDL and get parts of it deployed directly on to FPGA. Got it.
    - nickpsecurity 9y ago
      I said a separation kernel like the FOSS projects and commercial products dating back to 2005 I told Joanna about on Qubes mailing list which were compartmentalizing things on security-focused kernels. Aside from small TCB, they have optional mitifations for storage and timing channels. Aside from isolation, a standard practice on embedded side was including safe subsets of Java or Ada running right on the kernel to implement specific components more safely. So, basically just what was standard, deployed practice in high security over a decade ago. Optionally, I also pointed out people interested in developing solutions have options available now for safety or security on CPU side, too. They can do software, hardware, mix of both, whatever suits their purposes.
      - tptacek 9y ago
        Oh, and a safe subset of Java or Ada in the kernel. Well, that clears it all up.
        nickpsecurity 9y ago
        "safe subsets of Java or Ada running right on the kernel to implement specific components more safely. " "a safe subset of Java or Ada in the kernel." Done here since you're arguing against points Im not making. For anyone your strawman confused, the specific components are user-mode apps running on a separation kernel to minimize privilege. Not just piles of extra code in some kernel.
  - blattimwind 9y ago
    > For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? Which is literally what Qubes "Convert to trusted PDF" does. > My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. It would of course be preferable to have a secure PDF reader to begin with, but the complexities of the PDF format doesn't isn't really conducive to that.

dhimes 9y ago

Or weinzierl could print them and possibly rescan for further distribution.

JulianMorrison 9y ago
Convert to DjVu.
blattimwind 9y ago
Which is basically what Qubes "Convert to trusted PDF" does.
nickpsecurity 9y ago
My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. This might even be batched on simple hardware which itself has lower attack surface. Later on secure hardware like CHERI CPU albeit that can happen today if you have FPGA board and skills to run their HDL code. For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? ;) It might also be run back through similarly-deprivileged OCR to turn into a safer format. Gotta eyeball it if doing it that way. That said, there are fonts that work well with OCR that it might be converted to as part of image production if OCR is the goal in the first place. Could be a fun, little project teaching folks about a number of topics at once.
- tptacek 9y ago
  Your "first solution" would be to take a de novo PDF implementation written in C, "compile it with something that makes it memory-safe", and then port it to an L4 microkernel. Maybe bust out some HDL and get parts of it deployed directly on to FPGA. Got it.
  - nickpsecurity 9y ago
    I said a separation kernel like the FOSS projects and commercial products dating back to 2005 I told Joanna about on Qubes mailing list which were compartmentalizing things on security-focused kernels. Aside from small TCB, they have optional mitifations for storage and timing channels. Aside from isolation, a standard practice on embedded side was including safe subsets of Java or Ada running right on the kernel to implement specific components more safely. So, basically just what was standard, deployed practice in high security over a decade ago. Optionally, I also pointed out people interested in developing solutions have options available now for safety or security on CPU side, too. They can do software, hardware, mix of both, whatever suits their purposes.
    - tptacek 9y ago
      Oh, and a safe subset of Java or Ada in the kernel. Well, that clears it all up.
      - nickpsecurity 9y ago
        "safe subsets of Java or Ada running right on the kernel to implement specific components more safely. " "a safe subset of Java or Ada in the kernel." Done here since you're arguing against points Im not making. For anyone your strawman confused, the specific components are user-mode apps running on a separation kernel to minimize privilege. Not just piles of extra code in some kernel.
- blattimwind 9y ago
  > For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? Which is literally what Qubes "Convert to trusted PDF" does. > My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy. It would of course be preferable to have a secure PDF reader to begin with, but the complexities of the PDF format doesn't isn't really conducive to that.