Fwd: Question about RSA key access mechanism

Fri Apr 16 11:47:44 UTC 2021

Hi all,

Just to see if I can help prompt a response... :-)

Danış is working with me to try see how hard it is to
reproduce meltdown and snarf a private key. Problem-N
of many in doing that is knowing where private key
bits are used in OpenSSL - so far gdb seems to be showing
no accesses to p,q etc. when signing as part of new
TLS session establishment, which is a puzzle. Any/all
hints gratefully received...

Thanks,
S.

On 12/04/2021 09:57, Danis Ozdemir wrote:
> Hi all,
> 
> I hope all is good. My name is Danis Ozdemir, I'm a PhD student in Trinity
> College (Ireland) and I'm studying computer security. I'm trying to
> reproduce the meltdown attack as an effort to dive deep into the known
> attack types with some specific scenarios and "trying to see whether
> Meltdown could have been used against a web server making use of openssl
> libraries, running on an old, non-patched Linux kernel" is one of them. *Please
> notice that the intentions are purely academic here, rather than performing
> a real attack.*
> 
> Before investigating a more realistic scenario, I started with an 'open
> box' approach in which the openssl server process reveals the addresses of
> the sub fields of its private key (The private key and the certificate used
> below were created using the command 'openssl req -x509 -nodes -days 1000
> -newkey rsa:2048 -keyout priv.pem -out cert.pem', so they are RSA based.
> And I just used good, old printf in the function "ssl_set_pkey" in the file
> "ssl/ssl_rsa.c"):
> 
> # *LD_LIBRARY_PATH=${PWD} ./apps/openssl s_server -accept 54321 -cert
> my_keys/cert.pem -key my_keys/priv.pem -www*
> Could not read params of DH parameters from my_keys/cert.pem
> Using default temp DH parameters
> 
> 
> 
> 
> 
> 
> 
> 
> *DANIS - ssl_set_pkey - c->pkeys[0].privatekey : 0x55e4f9f01670  -
>   144Danis - ssl_set_pkey - pkey->keydata->n       : 0x55e4f9f13d50Danis -
> ssl_set_pkey - pkey->keydata->e       : 0x55e4f9f131e0Danis - ssl_set_pkey
> - pkey->keydata->d       : 0x55e4f9f05790Danis - ssl_set_pkey -
> pkey->keydata->p       : 0x55e4f9f05670Danis - ssl_set_pkey -
> pkey->keydata->q       : 0x55e4f9f058b0Danis - ssl_set_pkey -
> pkey->keydata->dmp1    : 0x55e4f9f18850Danis - ssl_set_pkey -
> pkey->keydata->dmq1    : 0x55e4f9f13800Danis - ssl_set_pkey -
> pkey->keydata->iqmp    : 0x55e4f9f13820*
> ACCEPT
> 
> Once the server is up and running, I get the real address of the sub field
> p using gdb:
> 
> # *ps -ef | grep -v grep | grep openssl*
> adminq    *1421*  1280  0 16:55 pts/1    00:00:00 ./apps/openssl s_server
> -accept 54321 -cert my_keys/cert.pem -key my_keys/priv.pem -www
> # *gdb*
> GNU gdb (Debian 8.2.1-2+b3) 8.2.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>      <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) *attach 1421*
> Attaching to process 1421
> Reading symbols from /home/adminq/Workspace/openssl/apps/openssl...(no
> debugging symbols found)...done.
> Reading symbols from /home/adminq/Workspace/openssl/libssl.so.3...(no
> debugging symbols found)...done.
> Reading symbols from /home/adminq/Workspace/openssl/libcrypto.so.3...(no
> debugging symbols found)...done.
> Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...Reading symbols
> from
> /usr/lib/debug/.build-id/d3/583c742dd47aaa860c5ae0c0c5bdbcd2d54f61.debug...done.
> done.
> Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...Reading
> symbols from
> /usr/lib/debug/.build-id/e9/1114987a0147bd050addbd591eb8994b29f4b3.debug...done.
> done.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from
> /usr/lib/debug/.build-id/18/b9a9a8c523e5cfe5b5d946d605d09242f09798.debug...done.
> done.
> Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from
> /usr/lib/debug/.build-id/f2/5dfd7b95be4ba386fd71080accae8c0732b711.debug...done.
> done.
> 0x00007efd06acd631 in __libc_accept (fd=4, addr=..., len=0x7ffca292907c) at
> ../sysdeps/unix/sysv/linux/accept.c:26
> 26 ../sysdeps/unix/sysv/linux/accept.c: No such file or directory.
> (gdb) *x/6x 0x55e4f9f05670*
> 0x55e4f9f05670: *0xf9f06b70 0x000055e4* *0x00000010* 0x00000010
> 0x55e4f9f05680: 0x00000000 0x0000000d
> (gdb) *watch * (unsigned long *) 0x55e4f9f06b70*
> Hardware watchpoint 1: * (unsigned long *) 0x55e4f9f06b70
> (gdb) c
> Continuing.
> 
> So, this output tells me that the content of p starts from the address
> *0x55e4f9f06b70* and it's length is 16*sizeof(unsigned long) bytes as p is
> of type bignum_st which has the following layout:
> 
> *struct bignum_st {*
> * BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit*
> * * chunks. */*
> * int top; /* Index of last used d +1. */*
> * /* The next are internal book keeping for bn_expand. */*
> * int dmax; /* Size of the d array. */*
> * int neg; /* one if the number is negative */*
> * int flags;*
> *};*
> 
> When I define a watchpoint for that address to verify that it has been
> accessed when a new client connects to the server and make the server
> continue, I can't see a hit which means this address hasn't been accessed. *I'm
> attaching the s_client output as a file, since it's longer compared to the
> outputs above.*
> 
> I then dumped the whole non-executable pages that were allocated for this
> process using ptrace to see whether another copy of the key was present and
> I couldn't find any copies. So, either I'm doing something wrong (which is
> the case, most probably) or there's another area which contains another
> representation of the key for security reasons (given the fact that the raw
> key content is accessible in the RAM, this one seems less likely).
> Therefore, assuming I'm doing something wrong, if you could tell me what it
> is, I'd be grateful.
> 
> Best regards,
> Danis Ozdemir
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x5AB2FAF17B172BEA.asc
Type: application/pgp-keys
Size: 10689 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210416/2928ad75/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210416/2928ad75/attachment-0001.sig>