-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
A presentation at DEFCON[1] last week showed how many Android applications were improperly using shared external storage on Android devices and could be vulnerable due to improper handling of temporary files. This was your basic: 1. Download a file from a trusted source (e.g. properly-authenticated, encrypted web connection) 2. Buffer the file in temporary storage 3. Read the file back from temporary storage type setup. The problem is that step 2b. might be "an attacker modifies the file". If step 4 is "use the file to update your own application", and the storage system is untrustworthy (which is the case on Android, since it's shared among all apps running on the device), then there is an opportunity to exploit that application. This got me to thinking about how Tomcat handles file uploads. Since Servlet 3.0, containers must provide the facility and Tomcat uses commons-fileupload to handle most of the heavy-lifting. One feature of that facility is the ability to buffer the file on a local disk if it exceeds some defined size -- to avoid creating large in-memory buffers for file uploads. So Tomcat does some form of the steps 1-3 above, except that the file isn't being downloaded... it's being uploaded. Now, it's really up to the application developer to be sure that the user should be allowed to upload a file, but assuming that user has been authenticated, then the application should be able to trust that Tomcat hasn't been subverted during steps 2-3. If the filesystem is hostile (yes, I know you have lots of problems if that's the case), then Tomcat might end up not delivering the same bytes to the application that were originally uploaded by the user. I'm curious whether anyone cares to look at this scenario in order to mitigate it. I can think of a few ways to mitigate such a potential vulnerability: 1. Tomcat computes a signature of the file as it's being written-out, computes the signature of the file as it's being read back-in for the application, and throws an exception if the file appears to be corrupted. Problems with this solution include not being able to detect the problem until most of the bytes have already been sent to the application. 2. Tomcat encrypts the file as its being written to the disk with a temporary symmetric key. Problems with this solution are additional resources (CPU) required for encryption. The LOE for either of the above doesn't seem very high. Is there any appetite for hardening of this type in Tomcat? Situations where the filesystem (or other programs running on the server) is untrustworthy are probably few and far-between, but there are indeed environments where applications are running under a security manager because those applications are untrusted. I didn't check to see whether Tomcat segregates temporary files for uploads between different applications, but I can see a scenario or two where Tomcat might want to protect an application from having its uploads tampered with. Thanks, - -chris [1] https://blog.checkpoint.com/2018/08/12/man-in-the-disk-a-new-attack-surf ace-for-android-apps/ -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlt23PwACgkQHPApP6U8 pFhyWQ/9E19l0tN1T37T/GPo3HsLZ+81MlJ/XKY+LrCQsKLG7Q+q1RnIOIjf3PnL uCy12JdH9eIZK96w35RXp6CP8H4t3FwaDEAoajUr1WYiqxi2L44cLxXd84gw0KGE IwF+yaY91YDIqMLnY7vf8Qq4rFygjML4o9Lu2PqffIdzgYbarWIYyhlx9yKX5FMe 1w+QD5qLvjVRWYig3WN5e+np0bDFZH6YAqQumQWDTLIFZrPq7BE6AlXX8cSXOhN8 LLvbULsusJYrDxiS2yximiyDema69vUfKutFKlRCgW0F+feyRSqy5RjjlUgY4KJ6 0gdwXKaHC4L7SaifKwjABQgIt7SIZPOTIaVIDEf+A2Ge+TcH3jiHJ/djcrY+MvoO 73ZOVr4sf0H3hKjDzDB3METpomP40CdjMhhgE/8WinORl/ZBJ6gPcP+wwsgEMo+I wbRnF/mraBaXHNuBZtx/gFciuUwUmyNBw7s2glYuDpC4cPa5r2naKdDz0an82ESu 9g1j2HYOW7htCCEnNYRTdeQPso3i5hkdr7rIW1pyRWspeoI5I5HxjQeIIrEYFRYa CZ1zmJXqezITvqS/yxPmkijnmT45kvtiVld4RROFwxNEmXghY+iDZ2pxvnZozhoI y2Uzu//8NFEeFNCyIV3iP9b3io/uX81iF51K5MqW/wwPyLlYLAg= =U/5d -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
