5 ms·

to be fair, it's possible that dropbox understands this and has taken steps to sandbox and isolate the process that does this fetching from the rest of their in

to be fair, it's possible that dropbox understands this and has taken steps to sandbox and isolate the process that does this fetching from the rest of their internal infrastructure. if this is done for the purposes of generating thumbnails/online previews, and the .doc includes external resources, what other choice do they have but to fetch it?

MiguelHudnandez 13y ago
> what other choice do they have but to fetch it? They could not fetch it and have a little blank bit in the thumbnail. Chances are they're using a library they didn't develop and did not think of the possibility of external resources being loaded. Edit: The most secure way I can think to handle preview generation is to have a virtual machine firewalled from the internet that previews a single document and is then reverted.
- Kudos 13y ago
  It makes more sense to have it fetch them via a proxy.
  - fleitz 13y ago
    Fetching via a proxy really doesn't do much, all you lose is the originating IP of the machine, the rest of the vulnerability still works. If you're thinking of egress filtering except for the proxy, you can just HTTP tunnel right through it.
    - MiguelHudnandez 13y ago
      Also there's a possibility of processing embedded links which point at your internal network. "How did this HTTP GET go through to my 'firewalled' PHPmyadmin site?" You have to treat all user input as if it's toxic.
      - fleitz 13y ago
        Brilliant! I wonder what kind of error messages LibreOffice embeds when it can't fetch a resource... could map out the internal network pretty quickly if it has distinct error messages. Also docx files are zip files which opens the possibility of a zipbomb. I wonder if LibreOffice has protection for zipbombs.
        chc 13y ago
        Don't you need recursive decompression to make a zip bomb go off?
        fleitz 13y ago
        Kinda... for 42.zip the first layer alone is 68GB albeit the final layer is 4.5 PB. It wouldn't surprise me one could engineer a docx bomb that would consume gigs of memory.
      - badman_ting 13y ago
        That's what I was thinking too. The only thing is that this process is running on an AWS instance, so it would have to be on Dropbox's VPN or something to have any such access. Either serendipitously or intentionally, I hope these boxes don't have any connection to anything sensitive.
- fleitz 13y ago
  Docker would probably be better as you don't have the huge VM overhead and is naturally reverts to it's original state.
  - MiguelHudnandez 13y ago
    I agree -- It's the same concept but much more efficient. I'd set up a docker to accept a single HTTP post with the document, and to return the thumbnail. The docker can then be shut down and a new instance spun up to wait for the next document to process. It might be wasteful to spin up a new docker for each instance, but it's the only way to prevent some exploit in LibreOffice[1] that might leak information somehow. A leak could be as terrible as embedding an entire document in the next thumbnail, or as simple as returning the wrong thumbnail (like from a previous request). [1] LibreOffice was the user-agent that phoned home in the article.
abstractbill 13y ago
The machine isn't the only thing at risk. Given this setup, it seems possible to use dropbox nodes to ddos an external target, just by uploading lots of documents, each containing lots of these links. It doesn't seem like they should be fetching external resources at all.
- milkshakes 13y ago
  again, it's not inconceivable that they understand this as well, and have some sort of rate limiting system in place. do you have a problem with google docs converting your office files?
  - werid 13y ago
    There was a case awhile back where Google docs helped a guy rack up a huge AWS bill. http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html http://www.behind-the-enemy-lines.com/2012/04/google-attack-...
    - veidr 13y ago
      Wow that is an interesting blog post, with a happy ending to boot (Amazon refunded the $1000+ in bandwidth fees, due to the accidental nature of the usage).
- danielweber 13y ago
  There are lots of services that generate traffic on your behalf. A very general rule is that you should have to send at least as many bytes as the service does, lest you become a DDOS multiplier. I don't see a .doc file getting small enough to outsize a HTTP request inside of it, even if you used some funky compression, but I'm willing to hear otherwise. One question would be if you could upload the document once and then somehow trigger a very tiny edit that causes them to rescan it.
  - abstractbill 13y ago
    One question would be if you could upload the document once and then somehow trigger a very tiny edit that causes them to rescan it. That does seem likely - dropbox tries to only upload diffs, when a file gets changed: https://www.dropbox.com/help/8/en https://www.dropbox.com/help/8/en
UnoriginalGuy 13y ago
It is possible but DropBox doesn't exactly have a good record on security.
njharman 13y ago
>> what other choice do they have but to fetch it? Firewall unexpected outbound connections on machines doing their processing.

MiguelHudnandez 13y ago

> what other choice do they have but to fetch it? They could not fetch it and have a little blank bit in the thumbnail. Chances are they're using a library they didn't develop and did not think of the possibility of external resources being loaded. Edit: The most secure way I can think to handle preview generation is to have a virtual machine firewalled from the internet that previews a single document and is then reverted.

Kudos 13y ago
It makes more sense to have it fetch them via a proxy.
- fleitz 13y ago
  Fetching via a proxy really doesn't do much, all you lose is the originating IP of the machine, the rest of the vulnerability still works. If you're thinking of egress filtering except for the proxy, you can just HTTP tunnel right through it.
  - MiguelHudnandez 13y ago
    Also there's a possibility of processing embedded links which point at your internal network. "How did this HTTP GET go through to my 'firewalled' PHPmyadmin site?" You have to treat all user input as if it's toxic.
    - fleitz 13y ago
      Brilliant! I wonder what kind of error messages LibreOffice embeds when it can't fetch a resource... could map out the internal network pretty quickly if it has distinct error messages. Also docx files are zip files which opens the possibility of a zipbomb. I wonder if LibreOffice has protection for zipbombs.
      - chc 13y ago
        Don't you need recursive decompression to make a zip bomb go off?
        fleitz 13y ago
        Kinda... for 42.zip the first layer alone is 68GB albeit the final layer is 4.5 PB. It wouldn't surprise me one could engineer a docx bomb that would consume gigs of memory.
    - badman_ting 13y ago
      That's what I was thinking too. The only thing is that this process is running on an AWS instance, so it would have to be on Dropbox's VPN or something to have any such access. Either serendipitously or intentionally, I hope these boxes don't have any connection to anything sensitive.
fleitz 13y ago
Docker would probably be better as you don't have the huge VM overhead and is naturally reverts to it's original state.
- MiguelHudnandez 13y ago
  I agree -- It's the same concept but much more efficient. I'd set up a docker to accept a single HTTP post with the document, and to return the thumbnail. The docker can then be shut down and a new instance spun up to wait for the next document to process. It might be wasteful to spin up a new docker for each instance, but it's the only way to prevent some exploit in LibreOffice[1] that might leak information somehow. A leak could be as terrible as embedding an entire document in the next thumbnail, or as simple as returning the wrong thumbnail (like from a previous request). [1] LibreOffice was the user-agent that phoned home in the article.

abstractbill 13y ago

The machine isn't the only thing at risk. Given this setup, it seems possible to use dropbox nodes to ddos an external target, just by uploading lots of documents, each containing lots of these links. It doesn't seem like they should be fetching external resources at all.

milkshakes 13y ago
again, it's not inconceivable that they understand this as well, and have some sort of rate limiting system in place. do you have a problem with google docs converting your office files?
- werid 13y ago
  There was a case awhile back where Google docs helped a guy rack up a huge AWS bill. http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html http://www.behind-the-enemy-lines.com/2012/04/google-attack-...
  - veidr 13y ago
    Wow that is an interesting blog post, with a happy ending to boot (Amazon refunded the $1000+ in bandwidth fees, due to the accidental nature of the usage).
danielweber 13y ago
There are lots of services that generate traffic on your behalf. A very general rule is that you should have to send at least as many bytes as the service does, lest you become a DDOS multiplier. I don't see a .doc file getting small enough to outsize a HTTP request inside of it, even if you used some funky compression, but I'm willing to hear otherwise. One question would be if you could upload the document once and then somehow trigger a very tiny edit that causes them to rescan it.
- abstractbill 13y ago
  One question would be if you could upload the document once and then somehow trigger a very tiny edit that causes them to rescan it. That does seem likely - dropbox tries to only upload diffs, when a file gets changed: https://www.dropbox.com/help/8/en https://www.dropbox.com/help/8/en

UnoriginalGuy 13y ago

It is possible but DropBox doesn't exactly have a good record on security.

njharman 13y ago

>> what other choice do they have but to fetch it? Firewall unexpected outbound connections on machines doing their processing.