Discussion:
Clear BIOS keybuffer
(too old to reply)
gb63
2009-03-14 19:14:03 UTC
Permalink
Raw Message
The last several versions of TrueCrypt such as 6.1a do clear the
keyboard buffer area in the RAM right after you enter the password.
The feature was added after only a few days of being reported.

BestCrypt Volume Encryption also upgraded their compiles, and so their
latest versions protect against that threat.

DriveCrypt Plus Pack has not announced any change that I know of, so
unless Shaun or someone corrects me, I think it may still retain the
buffer contents after bootup.

And I agree the retention of other RAM contents is over-hypped.
macarró
2009-03-15 08:19:54 UTC
Permalink
Raw Message
Post by gb63
The last several versions of TrueCrypt such as 6.1a do clear the
keyboard buffer area in the RAM right after you enter the password.
The feature was added after only a few days of being reported.
BestCrypt Volume Encryption also upgraded their compiles, and so their
latest versions protect against that threat.
DriveCrypt Plus Pack has not announced any change that I know of, so
unless Shaun or someone corrects me, I think it may still retain the
buffer contents after bootup.
And I agree the retention of other RAM contents is over-hypped.
I am using DriveCrypt Plus Pack, could anyone explain in an easy way
where the risk is with that?

For what I understand the preboot password gets stored somewhere in the
keyboard buffer after the computer has been switched off.

How long for does the preboot password remains stored in the keyboard
buffer in DCPP?

Thank you
gb63
2009-03-15 17:46:54 UTC
Permalink
Raw Message
Post by macarró
I am using DriveCrypt Plus Pack, could anyone explain in an easy way
where the risk is with that?
For what I understand the preboot password gets stored somewhere in the
keyboard buffer after the computer has been switched off.
How long for does the preboot password remains stored in the keyboard
buffer in DCPP?
Thank you
The problem is this: When you use Full Encryption you must enter the
password before Windows bootup starts. The keystrokes are stored in a
lower section of memory available to the bootloader. Once Windows
boots, it no longer needs the lower keybuffer - Windows traps all
future keystrokes with its own processes and memory buffers. But it
takes no action regarding the contents already in the lower buffer.

The main problem is not anything related to the 'cold boot' attack,
although that could also pose a possible risk. The problem is that a
small piece of assembly code could be placed by malware which could
read the contents of that original keybuffer. Your entire password
would remain there plainly visible during any time your computer was
on. Most encryption software will clear their own memory buffers of
entered passwords ( they use master keys extracted with the passwords
) but they had not provided any method of clearing the lower level
keyboard buffer.

At the time of the first report, I had used a hex editor on memory of
a machine running DCPP and the entire password was still there after
Windows booted. Then I tested a TC machine and one with BestCrypt
Volume Encryption. Same potential problem. Jetico rushed a first fix
followed by TrueCrypt a day or so later.

As far as I know, if you are using DCPP, it clears all passwords
within Windows allocated memory buffers but I think the lower buffer
is not cleared since I have seen no news from them otherwise. I
removed DCPP, not because of this, but I needed that machine for other
testing.

If Shaun is still with Securstar, perhaps he ( or anyone else on their
staff ) could provide additional progress reports.
Carsten Krueger
2009-03-15 16:57:13 UTC
Permalink
Raw Message
Post by gb63
The main problem is not anything related to the 'cold boot' attack,
although that could also pose a possible risk. The problem is that a
small piece of assembly code could be placed by malware which could
read the contents of that original keybuffer.
That's no real problem.

1) it only works with administrative rights
2) it could read the master key anyway (no need for passphrase)

greetings
Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
macarró
2009-03-16 07:22:19 UTC
Permalink
Raw Message
Post by gb63
Post by macarró
I am using DriveCrypt Plus Pack, could anyone explain in an easy way
where the risk is with that?
For what I understand the preboot password gets stored somewhere in the
keyboard buffer after the computer has been switched off.
How long for does the preboot password remains stored in the keyboard
buffer in DCPP?
Thank you
The problem is this: When you use Full Encryption you must enter the
password before Windows bootup starts. The keystrokes are stored in a
lower section of memory available to the bootloader. Once Windows
boots, it no longer needs the lower keybuffer - Windows traps all
future keystrokes with its own processes and memory buffers. But it
takes no action regarding the contents already in the lower buffer.
The main problem is not anything related to the 'cold boot' attack,
although that could also pose a possible risk. The problem is that a
small piece of assembly code could be placed by malware which could
read the contents of that original keybuffer. Your entire password
would remain there plainly visible during any time your computer was
on. Most encryption software will clear their own memory buffers of
entered passwords ( they use master keys extracted with the passwords
) but they had not provided any method of clearing the lower level
keyboard buffer.
At the time of the first report, I had used a hex editor on memory of
a machine running DCPP and the entire password was still there after
Windows booted. Then I tested a TC machine and one with BestCrypt
Volume Encryption. Same potential problem. Jetico rushed a first fix
followed by TrueCrypt a day or so later.
As far as I know, if you are using DCPP, it clears all passwords
within Windows allocated memory buffers but I think the lower buffer
is not cleared since I have seen no news from them otherwise. I
removed DCPP, not because of this, but I needed that machine for other
testing.
If Shaun is still with Securstar, perhaps he ( or anyone else on their
staff ) could provide additional progress reports.
Thanks a lot for taking the time to explain everything so clearly, I do
think this is a problem and since TC and Bestcrypt fixed it I hope DCPP
will do so too. Someone said an attacker could still read the masterkey
but if you use a .wav file as a masterkey that is not possible.
Carsten Krueger
2009-03-16 11:58:15 UTC
Permalink
Raw Message
Post by macarró
Someone said an attacker could still read the masterkey
but if you use a .wav file as a masterkey that is not possible.
Wrong. The master key is unencrypted in memory, it is needed to decrypt the
data on the fly.
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
macarró
2009-03-16 17:59:44 UTC
Permalink
Raw Message
Post by Carsten Krueger
Post by macarró
Someone said an attacker could still read the masterkey
but if you use a .wav file as a masterkey that is not possible.
Wrong. The master key is unencrypted in memory, it is needed to decrypt the
data on the fly.
I probably did not understand the concept very well, because when I
need to access my encryption keys I am asked for the password, which is
a stego key in my case.

I think those are two different passwords then.
n***@giganews
2009-03-15 18:00:22 UTC
Permalink
Raw Message
On Sun, 15 Mar 2009 09:19:54 +0100, macarró <***@no.spam> wrote:

( quotes snipped - - )

If you are interested, this is where TrueCrypt clears that buffer
in TrueCrypt 6.1a source Boot\Windows\BootConsoleIo.cpp -

void ClearBiosKeystrokeBuffer ()
{
__asm
{
push es
xor ax, ax
mov es, ax
mov di, 0x41e
mov cx, 32
cld
rep stosb
pop es
}
}
Shaun
2009-03-17 20:50:09 UTC
Permalink
Raw Message
Post by n***@giganews
( quotes snipped - - )
If you are interested, this is where TrueCrypt clears that buffer
in TrueCrypt 6.1a source Boot\Windows\BootConsoleIo.cpp -
void ClearBiosKeystrokeBuffer ()
{
__asm
{
push es
xor ax, ax
mov es, ax
mov di, 0x41e
mov cx, 32
cld
rep stosb
pop es
}
}
I just checked:

DcPPs key buffer clearing code is definately in the newer versions of
bootauth and it goes like this:

;Clear out bios's keyboard buffer.
;CPU's direction flag is cleared (cld) by caller of this routine.
;Seg Reg es is set to zero which we don't care about.
;saves flags and main cpu registers.
clear_bioskeybuffer:
pusha
pushf
xor ax,ax
mov es,ax
mov di,41eh
mov cx,32
clear_bioskeybuff: rep stosb
;clear out 32 bytes
popf
popa
ret


;regards,
;Shaun

Shaun Hollingworth
2009-03-17 20:16:18 UTC
Permalink
Raw Message
Hi,


DCPP's preboot "bootauth" code had the BIOS buffer clear code added at
the later of last year.

The internal buffers bootauth uses were always scrubbed after hashing.

Regards,
Shaun.
Post by gb63
The last several versions of TrueCrypt such as 6.1a do clear the
keyboard buffer area in the RAM right after you enter the password.
The feature was added after only a few days of being reported.
BestCrypt Volume Encryption also upgraded their compiles, and so their
latest versions protect against that threat.
DriveCrypt Plus Pack has not announced any change that I know of, so
unless Shaun or someone corrects me, I think it may still retain the
buffer contents after bootup.
And I agree the retention of other RAM contents is over-hypped.
Loading...