Re: Validation of class names in the autoload process
On Thu, 2013-10-17 at 09:27 +0200, Jordi Boggiano wrote:
> It has come to my attention that it's possible to abuse some
> autoloader by trying to autoload class names like
> "Foo\Bar\..\..\uploads\exploit.php" for example, which could be
> transformed to src/Foo/Bar/../../uploads/exploits.php, and then would
> require that file.
Are there codepaths where this can be injected from the outside? In the
unserializer this was prevented in
https://github.com/php/php-src/commit/ff8055fc5c9750482aac7a25a074aae0b1e64706
and some further commits, i.e.
https://github.com/php/php-src/commit/7126de4912d9d4c7499deb1f9239980400aa7ec7#diff-d697fc054b607bb0ffd7493daeb6a1afR616
Reasons against moving those in a more central place were
- Performance. checking always costs time (any autoloader is
way slower, shouldn't matter too much)
- There are more esoteric ways (mostly for extensions) to create
classes with "illegal" names (only illegal class names I know are
OCI-Lob and OCI-Collection from oci8 extension) an autoloader
(inside an extension) might produce them (I think that is unlikely
to exist in reality)
- Autoloader magic (developers sometimes do things I can't imagine)
- Autoloaders still have to verify (i.e. maximum length for the backend
used, some backends might require additional protection (i.e. \ needs
to be escaped))
I didn't consider the reasons to be strong, and I still don't. But maybe
I missed something.
For whitelisting "valid" classnames are described by
[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff\\]*
in the parser.
johannes
Thread (5 messages)