Marek Vavrecan

here you go https://drive.google.com/file/d/1ZLDIjY43IujRfQd8_fjxjr98l1nw5k6G/view?usp=sharing

here is output from ffprobe Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'new_recording.mp4': Metadata: major_brand : iso5 minor_version : 1 compatible_brands: isomiso5hlsf creation_time : 2021-02-22T15:33:24.000000Z Duration: 00:00:00.66, start: 0.000000, bitrate: 23437 kb/s Stream...

I think it could be fixed also in mp4Sig and add "iso" / "iso5" there

how does update to (SmartyCacheResourceMysql.php) `$content = $this->phpEncryption->decrypt($row['content']); ` from `$content = $row['content'];` and `"' . $this->phpEncryption->encrypt($content) . '"` from `"' . pSQL($content, true) . '"` will fix this security...

can you explain how just changing way how the data is written in SQL query will affect the exploitation? does it mean there is security issue of how pSQL is...

We compared 1.7.8.7 and 1.7.8.6 releases - and only relevant differences for major security vulnerability was just this change in SmartyCacheResourceMysql.php. It does not look right

is it safe to trust output of $this->phpEncryption->encrypt? If attack allowed to write custom content to smarty_cache, it would still go thought the encryption, or was there another point of...

i am just having a hard time to understanding the vulnerability - i though smarty_cache table is only accessed from SmartyCacheResourceMysql.php file

aha. So original exploit was injecting SQL at another location and this is just fix so that it can not execute custom code by writing to cache table.

this is minor change anyway, hope all SQL injections are fixed