-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
Bump. Does anyone have any comments on this? Thanks, - -chris On 8/17/18 10:34, Christopher Schultz wrote: > 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-su rf > > ace-for-android-apps/ > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluRNkIACgkQHPApP6U8 pFjEaQ/7BosHCHaMjWq/q0ZFW+srw8Ah71Fe6RYgT7I+Ta/6LLx8wmlrnUos23US vYfABOZ7INGzKmjMD7LL3KTYbtwiYE6BVeS2du/x5+G5nfQ/7dkhfIlRM8kLgfLB abB1e+vtKMRvSac2kXjdmcmB9J+j678mYsNDqoYQ7N47enDKLyWjBbtUHcIzJOcT RKXNgxP8B/JlxWaWJLyuKVvASXK8E+xt7oRMLYUkchUi7pDdo57f+vOE6B2OdX3N 2r8Vn3Qv6qY1AkwbVMXXorZIYmhn915/ZNKIsNCI4mAO3mrM62xFSz5KhSgRb7f3 4ZF48+IWcY8zEd3uU6GbEh33ZKMsFaYwnasV1Hh0Q4ghneHMzqiDcJsJIHOJrsKv 12BrCwhU6oM1AbkLUpmx4GUo+maeQafy9i9H1txXJyzx3nriJZc2Nxvc0ptkCfPt 8+D94+dfYuNDf/MQEA9rQrc807xMfp1AopE9ny2WrFOa4P6S7UwJFOHmGupZq5uo LYSs3P0zf6MJ0AK+oci9FY0fXff4Dj56PJoGrU5NvW6ecRsN4c96QKrhE+mwnkO+ U4Pxd+dfbdYL0HIQXJgenFyrj+KfNH8se9IGU4OkdfSblssf8BOMiDLF097NqhRO lu6iQL7puhNP3/3u1ytoNFoaiwR/JSX1NyAk0bgmk4y/5ko27Tc= =rWQ3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
