mirror of
https://github.com/OpenVPN/openvpn.git
synced 2026-05-22 01:46:42 -04:00
fa129d7153
The buffer we pass to tls_crypt_v2_extract_client_key contains the
entire received control channel packet. We should skip the opcode before
trying to read WKC.
This logic error is a second bug behind the XlabAI finding, next too the
too-strict ASSERT in tls_crypt_unwrap.
Also remove a too strict ASSERT in tls_crypt_unwrap. We already check
a few lines later for a too short packet and return a proper error
("packet too short").
XlabAI found a way of triggering this ASSERT that requires a tls-crypt-v2
client key that has a specific property (a specific byte need to have a
specific value, about 1/256 probability). If an attacker can get hold of
such a tls-crypt-v2 client key or observe a handshake using such a key,
the attacker can trigger the ASSERT, crashing the server. Setups that do
not use tls-crypt-v2 are not affected.
Independently, Cisco Talos reported a way to trigger this ASSERT with any
tls-crypt-v2 key but this requires the attacker to be also in possession
of the private key part of the tls-crypt-v2 client key or to inject packet
into a live session of a client session.
CVE: 2026-35058
Reported-By: XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com)
Reported-By: Guannan Wang (wgnbuaa@gmail.com
Reported-By: Zhanpeng Liu (pkugenuine@gmail.com)
Reported-By: Guancheng Li (lgcpku@gmail.com)
Reported-By: Emma Reuter of Cisco ASIG (TALOS-2026-2381)
Signed-off-by: Steffan Karger <steffan@karger.me>
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Change-Id: I623733c0476c98f436d19009ee8990693c1579b5
Private-URL: https://github.com/OpenVPN/openvpn-private-issues/issues/111
Acked-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: Gert Doering <gert@greenie.muc.de>
|
||
|---|---|---|
| .. | ||
| example_test | ||
| openvpn | ||
| openvpnserv | ||
| plugins | ||
| Makefile.am | ||
| README.md | ||
Unit Tests
This directory contains unit tests for openvpn. New features/bugfixes should be written in a test friendly way and come with corresponding tests.
Run tests
Tests are run by make check. A failed tests stops test execution. To run all
tests regardless of errors call make -k check.
Add new tests to existing test suite
Test suites are organized in directories. example_test/ is an example for a test suite with two test executables. Feel free to use it as a template for new tests.
Test suites
Test suites live inside a subdirectory of $ROOT/tests/unit_tests, e.g. $ROOT/tests/unit_tests/my_feature.
Test suites are configured by a Makefile.am. Tests are executed by testdrivers. One testsuite can contain more than one testdriver.
Hints
- Name suites & testdrivers in a way that the name of the driver says something about which component/feature is tested
- Name the testdriver executable
*_testdriver. This way it gets picked up by the default.gitignore- If this is not feasible: Add all output to a
.gitignore* Use descriptive test names:coffee_brewing__with_no_beans__failsvs.test34
- If this is not feasible: Add all output to a
- Testing a configurable feature? Wrap test execution with a conditional (see auth_pam for an example)
- Add multiple test-drivers when one testdriver looks crowded with tests
New Test Suites
- Organize tests in folders for features.
- Add the new test directory to
SUBDIRSinMakefile.am - Edit
configure.acand add the newMakefiletoAC_CONFIG_FILES - Run
./configure, and enable the feature you'd like to test - Make sure that
make checkruns your tests - Check: Would a stranger be able to easily find your tests by you looking at the test output?
- Run
./configure, and disable the feature you'd like to test - Make sure that
make checkdoes not run your tests