|
List Info Thread: Re: Zeroing sensitive memory chunks
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Re: Zeroing sensitive memory chunks |
|
List Info Thread: Re: Zeroing sensitive memory chunks
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
function
bar31:
pushl %ebp
movl %esp, %ebp
subl $40, %esp
leal -31(%ebp), %eax
movl %eax, 4(%esp)
movl $.LC2, (%esp)
call scanf
leave
ret
.size bar31, .-bar31
.section .rodata.str1.1
.LC3:
.string "%30s"
.text
.p2align 4,,15
-----
The simple PoC session transcript follows:
-----
$ cat poc.c
#include <ctype.h>
#include <stdio.h>
#include <string.h>
void pass(void)
{
char buffer[31];
printf("Password: ");
scanf("%30s", buffer);
memset(buffer, 0, sizeof(buffer));
}
int main(void)
{
pass();
return 0;
}
$ gcc -O -g -o poc poc.c
$ gdb poc
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as
"i386-marcel-freebsd"...
(gdb) b main
Breakpoint 1 at 0x8048450: file poc.c, line 15.
(gdb) run
Starting program: /some/path/poc
Breakpoint 1, main () at poc.c:15
15 {
(gdb) step
main () at poc.c:16
16 pass();
(gdb) step
pass () at poc.c:9
9 printf("Password: ");
(gdb) print &buffer
$1 = (char (*)[31]) 0xbfbfec69
(gdb) step
10 scanf("%30s", buffer);
(gdb)
Password: ASDFGHJKLQWERTYUIO
12 }
(gdb)
main () at poc.c:18
18 }
(gdb)
0x080483af in _start ()
(gdb) x/35c 0xbfbfec69
0xbfbfec69: 65 'A' 83 'S' 68 'D' 70 'F' 71 'G' 72
'H' 74 'J' 75 'K'
0xbfbfec71: 76 'L' 81 'Q' 87 'W' 69 'E' 82 'R' 84
'T' 89 'Y' 85 'U'
0xbfbfec79: 73 'I' 79 'O' 0 ' ' 1 ' 01' 0
' ' 0 ' ' 0 ' ' -36 'Ü'
0xbfbfec81: -20 'ì' -65 '¿' -65 '¿' 0 ' ' 0 ' ' 0
' ' 0 ' ' -104 '230'
0xbfbfec89: -20 'ì' -65 '¿' -65 '¿'
(gdb)
-----
Currently, I was not able to identify gcc's code that
removes the
memset in question, so if anyone has ideas -- it will be
appreciated.
Just now there should be no flaws in the geli code if not
dead code
elimination occurs for array sizes >= 32: all local
buffers that
are cleared by bzero() are at least 64 bytes. But there can
be
other parts of a kernel that needs to be verified and gcc's
conditions
for the memset elimination should be analyzed. I will
continue to
investigate.
And still, if some old/new gcc's (or other compilers,
although they
are not suspported for the kernel builds) will change their
mind
about elimination conditions for the tail memset(), we can
be in
trouble. Sure, stack-based variables can be rewritten by
further
calls to other functions, but it is better to be safe, then
sorry ;-/
And it seems not to matter that kernel library has its own
memset
implementation, because
a) gcc changes bzero -> memset in the single pass and the
internal
memset is tried first (gcc's builtins.c, lines 3529 and
down);
b) gcc tries to eliminate memset() even if there is such
local
function.
Here is the test example:
-----
$ cat poc1.c
#include <stdio.h>
#include <strings.h>
void *
memset(void *b, int c, size_t len)
{
char *bb;
for (bb = (char *)b; len--; )
*bb++ = c;
return (b);
}
int foo31()
{
char buffer[31];
scanf("%30s", buffer);
memset(buffer, 0, sizeof(buffer));
}
int bar31()
{
char buffer[31];
scanf("%30s", buffer);
bzero(buffer, sizeof(buffer));
}
int main()
{
bar31();
foo31();
return 0;
}
-----
As one can verify with 'gcc -O -S -o poc1.s poc1.c', there
will be no
cleaning in both foo31() and bar31().
> For example, OpenSSL has the OPENSSL_cleanse() function
whose purpose
> is two-fold (from