CVE-2018-10903

A flaw was found in python-cryptography versions between >=1.9.0 and <2.3. The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage.

A flaw was found in python-cryptography versions between >=1.9.0 and <2.3. The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage.

The python-cryptography and python-cryptography-vectors packages have been updated to version 2.3.1 and fixes the following security issue:

The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage (CVE-2018-10903).

A flaw was found in python-cryptography versions between >=1.9.0 and <2.3. The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage.

This update for python-cryptography fixes the following issues:

• CVE-2018-10903: The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries could have caused key leakage (bsc#1101820).

This update for python-cryptography fixes the following issues:

• CVE-2018-10903: The finalize_with_tag API did not enforce a minimum tag length. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries could have caused key leakage (bsc#1101820)

This update for python-cffi, python-cryptography and python-xattr fixes the following issues:

Security issue fixed:

• CVE-2018-10903: Fixed GCM tag forgery via truncated tag in finalize_with_tag API (bsc#1101820).

Non-security issues fixed:

python-cffi was updated to 1.11.2 (bsc#1138748, jsc#ECO-1256, jsc#PM-1598):

• fixed a build failure on i586 (bsc#1111657)

• Salt was unable to highstate in snapshot 20171129 (bsc#1070737)

• Update pytest in spec to add c directory tests in addition to testing directory.

Update to 1.11.1:

• Fix tests, remove deprecated C API usage
• Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary extensions (cpython issue #29943)
• Fix for 3.7.0a1+

Update to 1.11.0:

• Support the modern standard types char16_t and char32_t. These work like wchar_t: they represent one unicode character, or when used as charN_t * or charN_t[] they represent a unicode string. The difference with wchar_t is that they have a known, fixed size. They should work at all places that used to work with wchar_t (please report an issue if I missed something). Note that with set_source(), you need to make sure that these types are actually defined by the C source you provide (if used in cdef()).
• Support the C99 types float _Complex and double _Complex. Note that libffi doesn't support them, which means that in the ABI mode you still cannot call C functions that take complex numbers directly as arguments or return type.
• Fixed a rare race condition when creating multiple FFI instances from multiple threads. (Note that you aren't meant to create many FFI instances: in inline mode, you should write ffi = cffi.FFI() at module level just after import cffi; and in out-of-line mode you don't instantiate FFI explicitly at all.)
• Windows: using callbacks can be messy because the CFFI internal error messages show up to stderr-but stderr goes nowhere in many applications. This makes it particularly hard to get started with the embedding mode. (Once you get started, you can at least use @ffi.def_extern(onerror=...) and send the error logs where it makes sense for your application, or record them in log files, and so on.) So what is new in CFFI is that now, on Windows CFFI will try to open a non-modal MessageBox (in addition to sending raw messages to stderr). The MessageBox is only visible if the process stays alive: typically, console applications that crash close immediately, but that is also the situation where stderr should be visible anyway.
• Progress on support for callbacks in NetBSD.
• Functions returning booleans would in some case still return 0 or 1 instead of False or True. Fixed.
• ffi.gc() now takes an optional third parameter, which gives an estimate of the size (in bytes) of the object. So far, this is only used by PyPy, to make the next GC occur more quickly (issue #320). In the future, this might have an effect on CPython too (provided the CPython issue 31105 is addressed).
• Add a note to the documentation: the ABI mode gives function objects that are slower to call than the API mode does. For some reason it is often thought to be faster. It is not!

Update to 1.10.1:

• Fixed the line numbers reported in case of cdef() errors. Also, I just noticed, but pycparser always supported the preprocessor directive # 42 'foo.h' to mean 'from the next line, we're in file foo.h starting from line 42';, which it puts in the error messages.

Update to 1.10.0:

Issue #295: use calloc() directly instead of PyObject_Malloc()+memset() to handle ffi.new() with a default allocator. Speeds up ffi.new(large-array) where most of the time you never touch most of the array.

• Some OS/X build fixes ('only with Xcode but without CLT';).
• Improve a couple of error messages: when getting mismatched versions of cffi and its backend; and when calling functions which cannot be called with libffi because an argument is a struct that is 'too…

This update for python-cffi, python-cryptography fixes the following issues:

Security issue fixed:

• CVE-2018-10903: Fixed GCM tag forgery via truncated tag in finalize_with_tag API (bsc#1101820).

Non-security issues fixed:

python-cffi was updated to 1.11.2 (bsc#1138748, jsc#ECO-1256, jsc#PM-1598):

• fixed a build failure on i586 (bsc#1111657)

• Salt was unable to highstate in snapshot 20171129 (bsc#1070737)

• Update pytest in spec to add c directory tests in addition to testing directory.

• update to version 1.11.2:

  • Fix Windows issue with managing the thread-state on CPython 3.0 to 3.5

• Update pytest in spec to add c directory tests in addition to testing directory.

• Omit test_init_once_multithread tests as they rely on multiple threads finishing in a given time. Returns sporadic pass/fail within build.

• Update to 1.11.1:

  • Fix tests, remove deprecated C API usage
  • Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary extensions (cpython issue #29943)
  • Fix for 3.7.0a1+

• Update to 1.11.0:

  • Support the modern standard types char16_t and char32_t. These work like wchar_t: they represent one unicode character, or when used as charN_t * or charN_t[] they represent a unicode string. The difference with wchar_t is that they have a known, fixed size. They should work at all places that used to work with wchar_t (please report an issue if I missed something). Note that with set_source(), you need to make sure that these types are actually defined by the C source you provide (if used in cdef()).
  • Support the C99 types float _Complex and double _Complex. Note that libffi doesn't support them, which means that in the ABI mode you still cannot call C functions that take complex numbers directly as arguments or return type.
  • Fixed a rare race condition when creating multiple FFI instances from multiple threads. (Note that you aren't meant to create many FFI instances: in inline mode, you should write ffi = cffi.FFI() at module level just after import cffi; and in out-of-line mode you don't instantiate FFI explicitly at all.)
  • Windows: using callbacks can be messy because the CFFI internal error messages show up to stderr-but stderr goes nowhere in many applications. This makes it particularly hard to get started with the embedding mode. (Once you get started, you can at least use @ffi.def_extern(onerror=...) and send the error logs where it makes sense for your application, or record them in log files, and so on.) So what is new in CFFI is that now, on Windows CFFI will try to open a non-modal MessageBox (in addition to sending raw messages to stderr). The MessageBox is only visible if the process stays alive: typically, console applications that crash close immediately, but that is also the situation where stderr should be visible anyway.
  • Progress on support for callbacks in NetBSD.
  • Functions returning booleans would in some case still return 0 or 1 instead of False or True. Fixed.
  • ffi.gc() now takes an optional third parameter, which gives an estimate of the size (in bytes) of the object. So far, this is only used by PyPy, to make the next GC occur more quickly (issue #320). In the future, this might have an effect on CPython too (provided the CPython issue 31105 is addressed).
  • Add a note to the documentation: the ABI mode gives function objects that are slower to call than the API mode does. For some reason it is often thought to be faster. It is not!

• Update to 1.10.1:

  • Fixed the line numbers reported in case of cdef() errors. Also, I just noticed, but pycparser always supported the preprocessor directive # 42 'foo.h' to mean 'from the next line, we're in file foo.h starting from line 42';, which it puts in the error messages.

• update to 1.10.0:

• Issue #295: use calloc() directly instead of…

This update for python-cryptography, python-cryptography-vectors fixes the following issues:

• Update in SLE-15 (bsc#1177083, jsc#PM-2730, jsc#SLE-18312)

• Refresh patches for new version

• Update in SLE-15 (bsc#1176785, jsc#ECO-3105, jsc#PM-2352)

• update to 2.9.2

  • 2.9.2 - 2020-04-22
    • Updated the macOS wheel to fix an issue where it would not run on macOS versions older than 10.15.
  • 2.9.1 - 2020-04-21
    • Updated Windows, macOS, and manylinux wheels to be compiled with OpenSSL 1.1.1g.
  • 2.9 - 2020-04-02
    • BACKWARDS INCOMPATIBLE: Support for Python 3.4 has been removed due to low usage and maintenance burden.
    • BACKWARDS INCOMPATIBLE: Support for OpenSSL 1.0.1 has been removed. Users on older version of OpenSSL will need to upgrade.
    • BACKWARDS INCOMPATIBLE: Support for LibreSSL 2.6.x has been removed.
    • Removed support for calling public_bytes() with no arguments, as per our deprecation policy. You must now pass encoding and format.
    • BACKWARDS INCOMPATIBLE: Reversed the order in which rfc4514_string() returns the RDNs as required by RFC 4514.
    • Updated Windows, macOS, and manylinux wheels to be compiled with OpenSSL 1.1.1f.
    • Added support for parsing single_extensions in an OCSP response.
    • NameAttribute values can now be empty strings.

• Add openSSL_111d.patch to make this version of the package compatible with OpenSSL 1.1.1d, thus fixing bsc#1149792.

• bsc#1101820 CVE-2018-10903 GCM tag forgery via truncated tag in finalize_with_tag API

• Update in SLE-15 (bsc#1177083, jsc#PM-2730, jsc#SLE-18312)

• Include in SLE-15 (bsc#1176785, jsc#ECO-3105, jsc#PM-2352)

• update to 2.9.2:

  • updated vectors for the cryptography 2.9.2 testing

It was discovered that python-cryptography incorrectly handled certain inputs. An attacker could possibly use this to get access to sensitive information.