
CVE-2023-5217 Proof-of-Concept-Repository für libvpx v1.8.0, das eine Heap-Buffer-Overflow-Schwachstelle im VP8/VP9-Codec-SDK demonstriert, mit Unterstützung für Build- und Testvektoren.
README - 31. Januar 2019
Willkommen im WebM VP8/VP9 Codec SDK!
KOMPILIEREN DER ANWENDUNGEN/BIBLIOTHEKEN: Das verwendete Build-System ähnelt autotools. Das Bauen besteht im Allgemeinen darin, mit Ihren gewünschten Build-Optionen zu konfigurieren und dann GNU make zu verwenden, um die Anwendung zu bauen.
* Alle x86-Ziele benötigen den Yasm[1]-Assembler, der installiert sein muss[2].
* Alle Windows-Builds erfordern, dass Cygwin[3] installiert ist.
* Das Erstellen der Dokumentation erfordert Doxygen[4]. Wenn Sie dieses Paket nicht haben, wird die Option install-docs deaktiviert.
* Das Herunterladen der Daten für die Unit-Tests erfordert curl[5] und sha1sum. sha1sum wird über die GNU coreutils bereitgestellt, die standardmäßig auf vielen *nix-Plattformen sowie MinGW und Cygwin installiert sind. Falls coreutils nicht verfügbar ist, kann eine kompatible Version von sha1sum aus dem Quellcode erstellt werden[6]. Diese Anforderungen sind optional, wenn die Unit-Tests nicht ausgeführt werden.
[1]: http://www.tortall.net/projects/yasm
[2]: Für Visual Studio sollte die Basis-yasm-Binärdatei (nicht vsyasm) im PATH für Visual Studio sein. Für VS2017 reicht es aus, yasm-<version>-<arch>.exe in yasm.exe umzubenennen und zu platzieren in: Program Files (x86)/Microsoft Visual Studio/2017/<level>/Common7/Tools/
[3]: http://www.cygwin.com
[4]: http://www.doxygen.org
[5]: http://curl.haxx.se
[6]: http://www.microbrew.org/tools/md5sha1sum/
2. Out-of-Tree-Builds Out-of-Tree-Builds sind eine unterstützte Methode zum Bauen der Anwendung. Bei einem Out-of-Tree-Build wird der Quellbaum getrennt von den während der Kompilierung erzeugten Objektdateien gehalten. Zum Beispiel:
$ mkdir build
$ cd build
$ ../libvpx/configure <options>
$ make
3. Konfigurationsoptionen Das Skript 'configure' unterstützt eine Reihe von Optionen. Die Option --help kann verwendet werden, um eine Liste der unterstützten Optionen zu erhalten: $ ../libvpx/configure --help
Compiler-Analysatoren Compiler haben Sanitizer hinzugefügt, die Binärdateien mit Informationen über Adressberechnung, Speichernutzung, Threading, undefiniertes Verhalten und andere häufige Fehler instrumentieren. Um das Bauen von libvpx mit einigen dieser Funktionen zu vereinfachen, verwenden Sie tools/set_analyzer_env.sh vor dem Ausführen von configure. Es setzt den Compiler und die notwendigen Flags für das Bauen sowie Umgebungsvariablen, die vom Analyzer beim Testen der Binärdateien gelesen werden. $ source ../libvpx/tools/set_analyzer_env.sh address
Cross-Entwicklung Für die Cross-Entwicklung ist die bemerkenswerteste Option die --target-Option. Die aktuellste Liste der unterstützten Ziele finden Sie am Ende der --help-Ausgabe des configure-Skripts. Zum Zeitpunkt dieser Erstellung ist die Liste der verfügbaren Ziele:
arm64-android-gcc
arm64-darwin-gcc
arm64-linux-gcc
arm64-win64-gcc
arm64-win64-vs15
armv7-android-gcc
armv7-darwin-gcc
armv7-linux-rvct
armv7-linux-gcc
armv7-none-rvct
armv7-win32-gcc
armv7-win32-vs14
armv7-win32-vs15
armv7s-darwin-gcc
armv8-linux-gcc
mips32-linux-gcc
mips64-linux-gcc
ppc64le-linux-gcc
sparc-solaris-gcc
x86-android-gcc
x86-darwin8-gcc
x86-darwin8-icc
x86-darwin9-gcc
x86-darwin9-icc
x86-darwin10-gcc
x86-darwin11-gcc
x86-darwin12-gcc
x86-darwin13-gcc
x86-darwin14-gcc
x86-darwin15-gcc
x86-darwin16-gcc
x86-darwin17-gcc
x86-iphonesimulator-gcc
x86-linux-gcc
x86-linux-icc
x86-os2-gcc
x86-solaris-gcc
x86-win32-gcc
x86-win32-vs14
x86-win32-vs15
x86_64-android-gcc
x86_64-darwin9-gcc
x86_64-darwin10-gcc
x86_64-darwin11-gcc
x86_64-darwin12-gcc
x86_64-darwin13-gcc
x86_64-darwin14-gcc
x86_64-darwin15-gcc
x86_64-darwin16-gcc
x86_64-darwin17-gcc
x86_64-iphonesimulator-gcc
x86_64-linux-gcc
x86_64-linux-icc
x86_64-solaris-gcc
x86_64-win64-gcc
x86_64-win64-vs14
x86_64-win64-vs15
generic-gnu
Das Ziel generic-gnu kann in Verbindung mit der Umgebungsvariablen CROSS verwendet werden, um Architekturen zu cross-kompilieren, die nicht explizit aufgeführt sind, sofern die Toolchain eine Cross-GNU-(gcc/binutils)-Toolchain ist. Andere POSIX-Toolchains werden wahrscheinlich ebenfalls funktionieren. Um beispielsweise mit der Toolchain mipsel-linux-uclibc zu bauen, könnte der folgende Befehl verwendet werden (Hinweis: POSIX-SH-Syntax, passen Sie ihn bei Bedarf an Ihre Shell an):
$ CROSS=mipsel-linux-uclibc- ../libvpx/configure
Zusätzlich können die aufzurufenden ausführbaren Dateien durch Angabe der Umgebungsvariablen CC, AR, LD, AS, STRIP, NM überschrieben werden. Zusätzliche Flags können mit CFLAGS, LDFLAGS und ASFLAGS an diese ausführbaren Dateien übergeben werden.
VP8/VP9 TESTVEKTOREN: Die Testvektoren können mit dem Build-System nach dem Ausführen von configure heruntergeladen und verifiziert werden. Um ein alternatives Verzeichnis anzugeben, kann die Umgebungsvariable LIBVPX_TEST_DATA_PATH verwendet werden.
$ ./configure --enable-unit-tests $ LIBVPX_TEST_DATA_PATH=../libvpx-test-data make testdata
CODE-STIL: Der Codierungsstil, der von diesem Projekt verwendet wird, wird mit clang-format unter Verwendung der Konfiguration in der Datei .clang-format im Stammverzeichnis des Repositorys durchgesetzt.
Bevor Sie Änderungen zur Überprüfung pushen, können Sie Ihren Code formatieren mit:
$ clang-format -i --style=file
$(git diff --name-only --diff-filter=ACMR '.[hc]' '.cc')
Überprüfen Sie die Datei .clang-format auf die Version, die zum Generieren verwendet wurde, falls es Unterschiede zwischen Ihrer lokalen Formatierung und dem Überprüfungssystem gibt.
Siehe auch: http://clang.llvm.org/docs/ClangFormat.html
UNTERSTÜTZUNG Diese Bibliothek ist ein Open-Source-Projekt, das von seiner Community unterstützt wird. Bitte senden Sie eine E-Mail an [email protected], um Hilfe zu erhalten.