xpra icon
Bug tracker and wiki

Opened 5 weeks ago

Closed 2 weeks ago

#2329 closed defect (fixed)

md5 on FIPS-enabled Linux systems

Reported by: Eric Lemings Owned by: Eric Lemings
Priority: minor Milestone: 3.0
Component: platforms Version: 1.0.x
Keywords: Cc:

Description

On FIPS-enabled Linux systems, Python's hashlib.md5() function is considered
"unsafe" and does nothing except throw a ValueError? exception. A
patch is attached.

Attachments (2)

xpra-1.0.13.fips-md5-sha256.patch (6.3 KB) - added by Eric Lemings 5 weeks ago.
Xpra 1.x patch for FIPS-compliant checksums
xpra-2.5.2.fips-md5-sha256.patch (4.8 KB) - added by Eric Lemings 5 weeks ago.
Xpra 2.5.2 patch for FIPS-compliant checksums

Download all attachments as: .zip

Change History (7)

Changed 5 weeks ago by Eric Lemings

Xpra 1.x patch for FIPS-compliant checksums

Changed 5 weeks ago by Eric Lemings

Xpra 2.5.2 patch for FIPS-compliant checksums

comment:1 Changed 5 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to Eric Lemings

Thanks for reporting this issue.
I've only just glanced at the patches so far, the patch for v2.5.x looks fine but the patch for v1.0.x will cause hard to debug failures in the authentication modules: switching to sha1 (or sha256 for some - not sure why those are different) will cause the the authentication value provided by the client to not match the one generated by the server using a different hash.
(that's one of the changes since v1: clients can specify a list of hashes they support and we choose the strongest ones first)

comment:2 Changed 5 weeks ago by Antoine Martin

How about this:

  • r22933 use sha1 as fallback for window border color (no risk here)
  • r22934 switch to sha1 for pixel checksum debugging feature (and only support md5 in the client - for now)
  • r22935 update unit test
  • r22936 try all possible hashin algorithms for matching keys (configurable via env var) and warn if one is missing

All of this can be backported to v2.5.x

For v1.0.x, I am tempted to add a utility method to the autentication modules for doing the hmac and just failing every time: we can't do md5 and doing something else should never match.
(same for the proxy: returning an invalid string)

comment:3 Changed 5 weeks ago by Eric Lemings

I started with sha256 but later realized that sha1 is sufficient but didn't update them all hence the mix-up.

A utility wrapper sounds good. These patches are provided just as examples to fix the "bug".

comment:4 Changed 5 weeks ago by Antoine Martin

The untested fix for authentication modules in v1.0.x is in r22943: it will fail with a warning.

Backports for both v1.0.x and v2.5.x:

Will close after re-testing authentication with v1.0.x builds.

Last edited 5 weeks ago by Antoine Martin (previous) (diff)

comment:5 Changed 2 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

Minor fix in r23091 + r23092 (backport to v1.0 in r23093), which also makes it possible to disable md5 using (this is useful for testing):

XPRA_NOMD5=1 xpra ...

We patch it out from hashlib.algorithms_available only because hashlib.algorithms_guaranteed says: Note that ‘md5’ is in this list despite some upstream vendors offering an odd “FIPS compliant” Python build that excludes it.

Tested OK with version 1.0

Note: See TracTickets for help on using tickets.