-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Konstantin,
On 9/6/18 12:18, Konstantin Kolinko wrote: > пт, 17 авг. 2018 г. в 17:34, Christopher Schultz > <ch...@christopherschultz.net>: >> >> 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-s urf >> >> 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? Signed/sealed WAR files? > 2) Note that Tomcat does not use system temporary directory but > has its own temp directory. Sure, but there is conceptually no difference. > 3) Each web application has its own private temporary directory > (work/appname). The uploaded files are placed there, AFAIR. Any webapp would be able to write to any other webapp's work directory, if it knew the name of that directory. There is no protection provided by Tomcat > 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). The umask should already be set to a sane value, but Tomcat won't protect files from each other's web applications and, IIRC, a SecurityManager can't enforce that kind of protection, either. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluX2YMACgkQHPApP6U8 pFgayg//crXcXJm5vZSL/mhw+gclf7GPbx4RiktzS3U/184WA4ZMxjttZIqXaviO W5oeywH4Vzvac6xOoFi1Dx62qxq9XGDoi6rZN3ILs98JvxEkQzSMUbvC2TdVkTi2 4UKT0N8RqJuhiTUDCutQIXBiXBib86qPYisKQtNgcVHMTnZ7zlFrzvpAFGaogycJ RNeF2VLrE6htShuLiEhW4e8SxMUaKzQoKltd+HvvM/5xIuC4QpTPcgjvYO+qzYf/ eOuDIZqzg/ZmhmcTaDwJnWh7JifhabAfItmyfYiNDVwlVlI9LbSze7/D28clEG4v r470pCxiTHPOj2u/Usmd8+bEx9volk89KLMOTlwHpgzb0voWkgqTo93BQf42iqsU i7z5D87N/MNuRXNEZl7akN3EYnt4dXuVunPv47PA2H52Qs1UTO+rPvGdVQ2Ofl1g NiJ13lNjAP8OLGRM24oyEkYMdMLZCgk0IUnoo6vNgpI8cA0hI2fr0Gra2NStK8sg pWG9HSGBrvQ/8vFEXSfxpSkg3aZyz+o+54zc905RagqYbtWk3al/NrdDgTryF8o7 s4P5iAsR/Sm8e1yck3z65iRW7KfIgxVM1tOjNIs4F3n7ozs0oIxWq7KPC2xKTJ7m g8c4/0qFjRRoq3YQWGyLFwY9VDa+pIrGJh0EnaTdgKhvfrTOL+E= =cxpk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
