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.htmlThis 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
Attachment:
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
