f4e2e91d4b
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#remove_disable_classes_ini_setting This took longer to merge than expected but the initial motivation from 2 years ago still applied: As described in the email to the PHP internals list [1] this feature is fundamentally broken and pointless. Only internal classes can be disable which brings the following observation. On a minimal build of PHP, with only the mandatory extensions enabled, there are 148 classes/interfaces/traits defined. [2] Other than the SPL ones (and even then), disabling any of these classes will cause issues within the engine. Moreover, the SPL ones are not a security concern. Therefore, any other class that can be disabled must come from an extension that can be disabled altogether. And "disabling" a class from an extension without disabling said extension will render it useless anyway. If a hosting provided is concerned about an extension, then it should not enable it in the first place. Not break it ad hoc. Considering the above, I cannot see how this functionality was ever useful. This is in stark contrast to the disable_functions INI setting, which can be used to selectively remove functionality of an extension without breaking it overall. What makes this setting particularly broken is that it does not unregister the class, it only overwrites the create CE handler to emit a warning and purge the properties and function hashtables. This leads to various use after free, segfaults, and broken expectations for the engine and extensions which define said classes. On top of that, it is possible to actually instantiate such a class (and even classes which actually disallow this like ext/imap) in userland, and pass it to function that are typed against said class without raising a TypeError. However, when trying to do anything with said object stuff is going to explode in countless ways. [1] https://news-web.php.net/php.internals/120896 [2] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b
Fuzzing SAPI for PHP
The following ./configure options can be used to enable the fuzzing SAPI, as well as all available fuzzers. If you don't build the exif/json/mbstring extensions, fuzzers for these extensions will not be built.
CC=clang CXX=clang++ \
./configure \
--disable-all \
--enable-fuzzer \
--with-pic \
--enable-debug-assertions \
--enable-address-sanitizer \
--enable-exif \
--enable-mbstring
The --with-pic option is required to avoid a linking failure. The --enable-debug-assertions option can be used to enable debug assertions despite the use of a release build.
You can combine fuzzing with --enable-address-sanitizer, --enable-undefined-sanitizer or --enable-memory-sanitizer. The first two options can also be used together.
You will need a recent version of clang that supports the -fsanitize=fuzzer-no-link option.
When running make it creates these binaries in sapi/fuzzer/:
php-fuzz-parser: Fuzzing language parser and compilerphp-fuzz-unserialize: Fuzzing unserialize() functionphp-fuzz-unserializehash: Fuzzing unserialize() for HashContext objectsphp-fuzz-json: Fuzzing JSON parserphp-fuzz-exif: Fuzzingexif_read_data()function (requires --enable-exif)php-fuzz-mbstring: Fuzzingmb_convert_encoding()(requires--enable-mbstring)php-fuzz-mbregex: Fuzzingmb_ereg[i]()(requires --enable-mbstring)php-fuzz-execute: Fuzzing the executorphp-fuzz-function-jit: Fuzzing the function JITphp-fuzz-tracing-jit: Fuzzing the tracing JIT
Some fuzzers have a seed corpus in sapi/fuzzer/corpus. You can use it as follows:
cp -r sapi/fuzzer/corpus/exif ./my-exif-corpus
sapi/fuzzer/php-fuzz-exif ./my-exif-corpus
For the unserialize fuzzer, a dictionary of internal classes should be generated first:
sapi/cli/php sapi/fuzzer/generate_unserialize_dict.php
cp -r sapi/fuzzer/corpus/unserialize ./my-unserialize-corpus
sapi/fuzzer/php-fuzz-unserialize -dict=$PWD/sapi/fuzzer/dict/unserialize ./my-unserialize-corpus
For the unserializehash fuzzer, generate a corpus of initial hash serializations:
sapi/cli/php sapi/fuzzer/generate_unserializehash_corpus.php
cp -r sapi/fuzzer/corpus/unserializehash ./my-unserialize-corpus
sapi/fuzzer/php-fuzz-unserializehash ./my-unserialize-corpus
For the parser fuzzer, a corpus may be generated from Zend test files:
sapi/cli/php sapi/fuzzer/generate_parser_corpus.php
mkdir ./my-parser-corpus
sapi/fuzzer/php-fuzz-parser -merge=1 ./my-parser-corpus sapi/fuzzer/corpus/parser
sapi/fuzzer/php-fuzz-parser -only_ascii=1 ./my-parser-corpus
For the execute, function-jit and tracing-jit fuzzers, a corpus may be generated from any set of test files:
sapi/cli/php sapi/fuzzer/generate_execute_corpus.php ./execute-corpus Zend/tests ext/opcache/tests/jit
sapi/fuzzer/php-fuzzer-function-jit ./execute-corpus
For the mbstring fuzzer, a dictionary of encodings should be generated first:
sapi/cli/php sapi/fuzzer/generate_mbstring_dict.php
sapi/fuzzer/php-fuzz-mbstring -dict=$PWD/sapi/fuzzer/dict/mbstring ./my-mbstring-corpus
For the mbregex fuzzer, you may want to build the libonig dependency with instrumentation. At this time, libonig is not clean under ubsan, so only the fuzzer and address sanitizers may be used.
git clone https://github.com/kkos/oniguruma.git
pushd oniguruma
autoreconf -vfi
./configure CC=clang CFLAGS="-fsanitize=fuzzer-no-link,address -O2 -g"
make
popd
export ONIG_CFLAGS="-I$PWD/oniguruma/src"
export ONIG_LIBS="-L$PWD/oniguruma/src/.libs -l:libonig.a"
This will link an instrumented libonig statically into the PHP binary.