[Pkg-openssl-devel] Fwd: RDRAND for openssl should be disabled by default but it isnt

[report.problemissue at secure.mailbox.org]

-------- Forwarded Message --------
Subject: RDRAND for openssl should be disabled by default but it isnt
Date: Sat, 17 Sep 2022 22:19:30 +0200
From: report.problemissue at secure.mailbox.org
To: security at debian.org
CC: "openssl@"@packages.debian.org

openssl on bullseye and bookworm/sid/testing is affected

#begin
[OPSECfiltered]@OPSECfiltered:~$ openssl version ; openssl version -f ; 
openssl engine -c -t -tt -vvvv
OpenSSL 1.1.1n  15 Mar 2022
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall 
-Wa,--noexecstack -g -O2 
-ffile-prefix-map=/build/openssl-qQYEec/openssl-1.1.1n=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time 
-D_FORTIFY_SOURCE=2
(rdrand) Intel RDRAND engine
  [RAND]
      [ available ]
(dynamic) Dynamic engine loading support
      [ unavailable ]
      SO_PATH: Specifies the path to the new ENGINE shared library
           (input flags): STRING
      NO_VCHECK: Specifies to continue even if version checking fails 
(boolean)
           (input flags): NUMERIC
      ID: Specifies an ENGINE id name for loading
           (input flags): STRING
      LIST_ADD: Whether to add a loaded ENGINE to the internal list 
(0=no,1=yes,2=mandatory)
           (input flags): NUMERIC
      DIR_LOAD: Specifies whether to load from 'DIR_ADD' directories 
(0=no,1=yes,2=mandatory)
           (input flags): NUMERIC
      DIR_ADD: Adds a directory from which ENGINEs can be loaded
           (input flags): STRING
      LOAD: Load up the ENGINE specified by other settings
           (input flags): NO_INPUT

security_watch_guard: This action has been reported to a supervisor 
team. UID trustlevel degraded until distrust clearance. The lecture says

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these four things:

     #1) RESPECT THE PRIVACY OF OTHERS!
     #2) THINK BEFORE you TYPE.
     #3) With GREAT POWER comes GREAT RESPONSIBILITY
     #4) If something FEELS WRONG it probably IS WRONG.
     	Use a SECURE LINE to CONTACT THE SUPERVISOR TEAM
     	BEFORE YOU AUTHORIZE OR PROCEED in this case.

security_watch_guard: supervisor token recognized. Distrust clearance 
done. Trustlevel resetted. This action was logged.

#end

shows RDRAND engine is default engine (if cat /proc/cpuinfo shows flags 
rdrand rdseed aes, platform supports RDRAND/AES-NI) and it was not built 
with the OPENSSL_NO_RDRAND parameter.
https://wiki.openssl.org/index.php/Library_Initialization#ENGINEs_and_RDRAND 
shows snares. Several calls can reintroduce RDRAND if it was unloaded 
before.

"A call to ENGINE_load_builtin_engines loads all built-in engines, 
including those for AES_NI instructions and RDRAND. After the call, 
OpenSSL will use the engines for AES encryption and random number 
generation, if available. In this case, RDRAND will be the only source 
of random numbers. ". shows it uses RDRAND as one and only source of 
random numbers. Not a good idea.

"Future version of the library will change the default behavior. That 
is, in the future, you will have to explicitly call ENGINE_load_rdrand 
if you want to use RDRAND. The change has been checked in, but its only 
available through git at the moment." shows the default behaviour needs 
to be changed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732710
debian/patches/no_default_rdrand.patch is not applied anymore.

https://trac.torproject.org/projects/tor/ticket/10402 shows the 
Torproject is disabling RDRAND usage when HardwareAccel is enabled via 
workaround.

https://seclists.org/fulldisclosure/2013/Dec/99 shows building openssl 
with OPENSSL_NO_RDRAND is recommended.

https://www.schneier.com/blog/archives/2013/09/surreptitiously.html and 
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J show 
Intel applied pressure to let /dev/random rely on RDRAND instruction 
only. Intel is a strategic partner of ... who wants to weaken encryption 
for national security reasons, putting all users and organizations in 
jeopardy.

Using RDRAND as only source of random numbers allows side-channel 
attacks like CrossTalk 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543 on virtual 
machines where microcode updates can not be applied. This affects 
multiuser cloud environments and hosters of virtual machines with 
RDRAND/AES-NI supporting hypervisors and all connections made from these 
virtual machines.

“Arguing that you don't care about the right to privacy because you have 
nothing to hide is no different than saying you don't care about free 
speech because you have nothing to say.”
"Wer die Wahrheit nicht weiß, der ist bloß ein Dummkopf. Aber wer sie 
weiß und sie eine Lüge nennt, der ist ein Verbrecher."
With this in mind consider disabling RDRAND for openssl on Debian 
oldstable, stable and bookworm/testing/sid as one and only source of 
random numbers in openssl. RDRAND could include a backdoor. If it is 
backdoored it downgrades the security of millions of Debian users 
connections.

DSA number is desired!

Disclaimer of liability: This email was send without encryption and 
signing. Every information in this message could be manipulated by 
anyone who had access to it.


nameless privacy fighter