Re: Securing temporary file-uploads

[Christopher Schultz <ch...@christopherschultz.net>]

-----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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org