пт, 17 авг. 2018 г. в 17:34, Christopher Schultz <[email protected]>: > > 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/
Keep it simple. 1) If filesystem is not trustworthy, what prevents someone from injecting compiled classes, JSPs, or modifying essential configuration files? 2) Note that Tomcat does not use system temporary directory but has its own temp directory. 3) Each web application has its own private temporary directory (work/appname). The uploaded files are placed there, AFAIR. 4) If one is concerned, it is possible to run with a more restrictive umask (limiting access from other OS users to the created files) and with Security Manager (limiting access from other web applications to each other). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
