tracker issue : CF-4206294

select a category, or use search below
(searches all categories and all time range)

Class cache corruption causes unexpected behaviour

| View in Tracker

Status/Resolution/Reason: Open//

Reporter/Name(from Bugbase): Daniel G. / ()

Created: 12/09/2019

Components: Caching

Versions: 2016

Failure Type: Non Functioning

Found In Build/Fixed In Build: 2016.0.09.314003 /

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / CentOS 7.2

Vote Count: 0

Problem Description:
When the option to save class files to disk is enabled (Server Settings -> Caching -> Save class files) and Coldfusion is unable to store the file correctly, it is never attempted to fix after a restart, causing erratic behaviour ( java.lang.ClassNotFoundException when calling (cfinvoke) methods that are available on the files on disk).

The probable cause would be, that the cache of java class files is not protected by a checksum, thus coldfusion does not notice cache corruption and never attempts to fix the cache.

Steps to Reproduce:
Setup a method that can be cvinvoke-ed and another file that invokes said method. Fill the disk of the partition where cf tries to store the class file (to prevent CF from storing it correctly) or find another way to cause corruption of class cache, then restart the server. CF won't be able to store the compiled class file correctly. Might need some fiddling (perhaps CF only writes partial class files or something like that? Check the source that writes out class file cache.).

Actual Result:
CF being unable to call valid functions (that are valid in the source code, but not in the corrupted class file cache), causing the CF developers to comb their source endlessly for the mistake they made (which they didn't...).

Expected Result:
CF trying to re-build class file cache from source files when class file cache is unable to be used or CF terminating with a fatal error, depending on your policy on that.

Any Workarounds:
Disable "Save class file" option, restart CF, re-enable "Save class file" option, restart CF.

See also:
Attached stacktrace



Btw. if my assumption that CF does not protect the class file cache by a checksum of some sort is correct, that also means that an attacker with access to the class file cache file can get CF to execute code of his choice under the CF's user, since he can just modify the class files in the cache to execute whatever he wants. Might be a potential attack vector, if the attacker cannot modify the source code, but can modify the class file cache. Depends on where / how it's stored I guess.
Comment by Daniel G.
31942 | December 09, 2019 01:48:48 PM GMT