Re: Securing temporary file-uploads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 9/6/18 12:18, Konstantin Kolinko wrote: > пт, 17 авг. 2018 г. в 17:34, Christopher Schultz > : >> >> 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/
Re: Securing temporary file-uploads
пт, 17 авг. 2018 г. в 17:34, Christopher Schultz : > > 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Securing temporary file-uploads
-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: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > -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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Securing temporary file-uploads
-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
