I talk about joomla/filter/input.php (516ff) of Joomla 3.4.5.
In this block an archive file is completely parsed using strstr() against character sequences like ".php" or ".py". This does not meet the intention to find script files within archives because
(a) There is a good chance that the compressor producing the archive file generates output like ".py" or ".php". So we have a false positive just as result of compression.
(b) Script files within e.g. a tgz file can't be seen this way because files are first streamed into a single tar file which is then compressed.
Because these checks are new in J! 3.4 and most extensions doesn't switch off them I suggest to deactivate this test by default by setting 'fobidden_ext_in_content' => false
(please note the typo
This corresponds to my post http://forum.joomla.org/viewtopic.php?f=715&t=894174&p=3338980#p3338980 on The Joomla! Forum.
Labels |
Added:
?
|
Category | ⇒ | Libraries |
Status | New | ⇒ | Confirmed |
Just wanted to login and confirm this. I've tried uploading two zip files, one from a client (a SCORM package) and one of my own making containing some .mp4 files. Both are well over 100Mb and both fail when strstr() finds .py and .pl in them even though there are no such files in the archive. This is on Joomla 3.6.2. Any idea when we might get a patch? I've set fobidden_ext_in_content
to false in order to have a functioning media manager.
Are there any updates? @
Status | Confirmed | ⇒ | Duplicate Report |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-31 04:43:40 |
Closed_By | ⇒ | franz-wohlkoenig | |
Rel_Number | 0 | ⇒ | 15563 |
Relation Type | ⇒ | Duplicate of |
Status | Duplicate Report | ⇒ | Closed |
Closed_Date | 2017-05-31 04:43:40 | ⇒ | 2017-05-31 04:43:41 |
Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
Rel_Number | 15563 | ⇒ | 0 |
Relation Type | Duplicate of | ⇒ |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/8197
I've this issue as well with uploading a zip-file; which makes no sense to get scanned with plain data through the zip. I got a false positive with the '.pl' inside the zip-code of a 62MB file. The probability to get a false positve e.g. a substring with "pl." is 256^3 => (1:16777216) 62MB --> this is about 370%; with all the other extensions together (php,..inc,pl,cgi,fcgi,java,jar,py): the probability increases to 2/(256^3)+ 4/(256^4) ca. 1 : 8 300 000; with my 62 MB, the probability is >7 !! I.e. with a file of 100 MB, this is almost every time a false positive.
Because the get of the class JInputFiles calls the JFilterInput::isSafeFile() without the possibilty to unset any options, I had to change my uploading extension to the unsecure 'raw' in
$this->input->files->get('filename','','raw');
instead of->get('filename')
not only the typo "fobidden" , it makes no sense to scan through ".php" than with ".phps", ".php5", ...
the ".php" is part of ".phps" as well as ".php5", ".php3", ".php4" and returns false.
Thomas