Since v.2.05b bash supports memory scrambling. From the changelog: There is a new configuration option `--enable-mem-scramble', controls bash malloc behavior of writing garbage characters into memory at allocation and free time. This option is enabled by default for most systems. The feature is implemented by the custom bash malloc/free functions (lib/malloc/malloc.c), which are built if opt_bash_malloc=yes. For most architectures running Linux, that is the default. However, the current ebuild disables bash_malloc unconditionally by setting --without-gnu-malloc. While malloc from glibc might have better performance, it could be reasonable to allow users to choose somewhat better security.
"somewhat" is an understatement. crashing the shell is easy to do, so randomizing the memory is pretty useless. feel free to post a patch to add a local USE flag for this
> crashing the shell is easy to do, so randomizing the memory is pretty useless. I disagree. In general, an adversary must feed a shell with some data in order to crash it. If we keep the shell instance working with sensitive data protected from malicious inputs, memory scrambling can considerably enhance the security. Notice that many crypto products overwrite memory used for keys etc.
Created attachment 205834 [details, diff] adds memory scrambling support A patch against bash-4.0_p28.ebuild adds memscramble USE flag enabling the bash malloc.
overwriting crypto memory is irrelevant as the kernel protects memory leakage between processes. the only thing you could read out of memory is stuff the shell itself has put in. why cant you use $(use_with memscramble bash-malloc) ? your comment also has a typo (it says USE=scramble). fix these issues and add a patch for metadata.xml and i'll throw it in.
> kernel protects memory leakage between processes Sure. It does not protect freed memory. > the only thing you could read out of memory is stuff the > shell itself has put in. Assume that the whole work with sensitive data has to be done by a shell script. AFAIK, we have no pointers, malloc, memset, etc. Thus if we have read some data into a variable, we depend solely on the shell's memory management in wiping the data. > why cant you use $(use_with memscramble bash-malloc) ? When the flag is set, it returns --with-bash-malloc, which is the default on x86/amd64-linux and others. Is it safe to give this option on *unsupported* arches? Won't it force using of the bash malloc? Bash configure script reads: opt_bash_malloc=yes ... case "${host_cpu}-${host_os}" in alpha*-*) opt_bash_malloc=no ;; ... esac ... if test "${with_bash_malloc+set}" = set; then withval=$with_bash_malloc; opt_bash_malloc=$withval fi Please check.
Created attachment 205875 [details, diff] adds memory scrambling support
the kernel protects all memory from being read. it just does not proactively scrub it when it is freed. so while your "sensitive" data may stick around for a while, no userspace process will ever be able to access it without proper privileges and kernel hooks. and any user who has that access already can read your "sensitive" data all they like. also, i dont think there is any direction relation between shell code and the actual memory that bash is using. i.e. you have no api at all to force a free() on memory that contains "sensitive" data. you're simply relying on the good graces of bash and hoping that it just happens to do what you want. i havent read the code, but i doubt that bash wastes time calling free() on all of its memory just before an exec. after all, it has no way of guaranteeing that the exec actually succeeds. i looked at the configure options a bit and the bash-malloc option does not correlate directly to memscrambling. it is just a matter of the memscrambling option (--enable-mem-scramble) only works when the bash-malloc option is used. so you need to add $(use_enable mem-scramble) to the econf. and might as well rename the USE flag to match the configure option ? ;) you're right about the defaults of bash-malloc and being supported on a few arches, i'd rather have a build error be thrown in the face of people than let them think the option was properly respected.
> the kernel protects all memory from being read. it just does not proactively > scrub it when it is freed. If we also suppose that the standard malloc always mmaps zeroes onto allocated memory, we are pretty secure unless an adversary can access the memory physically, e.g., soon after the system shutdown. :) > you're simply relying on the good graces of bash and hoping that it just > happens to do what you want. That could be better than nothing. > you need to add $(use_enable mem-scramble) to the econf this is enabled by default for all relevant (i.e. except SCO Unix) systems, but I'll add it for the sake of clarity. > i'd rather have a build error be thrown If you are sure that the bash malloc simply won't be built on an unsupported arch, rather than work improperly, being built "successfully"...
Created attachment 206527 [details, diff] adds memory scrambling support
glibc doesnt handle sanitizing memory from the kernel (no mmap tricks). the kernel handles all of it via the MMU -- glibc asks for anonymous memory and the kernel will zero out a page as soon as a read/write happens to it (page fault). i have no idea wrt systems attempting to use mem-scramble and it hasnt been tested on their particular configuration. guess we'll find out ;). added your patch, thanks http://sources.gentoo.org/app-shells/bash/bash-4.0_p33.ebuild?r1=1.1&r2=1.2
