[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 20 Jan 2016 14:34:21 +0100
From: Yann Droneaud <ydroneaud@...eya.com>
To: oss-security@...ts.openwall.com
Subject: Re: Qualys Security Advisory - Roaming through the
OpenSSH client: CVE-2016-0777 and CVE-2016-0778
Hi,
Le lundi 18 janvier 2016 à 14:05 +0100, Florian Weimer a écrit :
> On 01/15/2016 01:56 PM, Yann Droneaud wrote:
> > Le vendredi 15 janvier 2016 à 12:06 +0100, Florian Weimer a écrit :
> > > On 01/14/2016 06:13 PM, Qualys Security Advisory wrote:
> > > > Internal stdio buffering is the most severe of the three
> > > > problems discussed in this section, although GNU/Linux is not
> > > > affected because the glibc mmap()s and munmap()s (and therefore
> > > > cleanses) stdio buffers.
> > >
> > > This will change in glibc 2.23, stdio will use regular malloc and
> > > free for its buffers. I did not expect this change to have
> > > security implications. Considering that the actual bug lies
> > > elsewhere, and stdio usage is based on copying out of the buffer
> > > (so leaks can still happen elsewhere), I do not wish to revert
> > > this change.
> > >
> >
> > Would setvbuf(stream, NULL, _IONBF, 0); be used to disable buffer
> > before reading/writting sensible data to a stream ?
>
> That entirely depends on how the data is read or written. glibc will
> make additional copies on the heap in some cases. In any case, this
> is an implementation detail.
>
So one should probably not use stdio stream (fgets(), fread(),
fscanf(), fputs(), fwrite(), etc.) to load sensible data from/to,
depending on the threat model. In particular, in case it's not from/to
a local socket nor a pipe, reading or writing such data in cleartext
might be bad idea after all).
> Even if the data is gone from the process image, the kernel or its
> hypervisor may still keep copies, particularly if the data is (or was
> once) on the file system. It is very hard to override data reliably
> on modern systems.
If an userspace application is allowed to access sensitible
information, this imply the kernel is also allowed to access it.
Userspace has to trust kernel/hypervisor. And kernel/hypervisor has to
work so that they are trustworthy from the userspace point of view,
that is, to not exchange data between namespaces, users, processes when
not explicitly allowed to.
AFAICT, having shadows / ghosts copies in kernelspace is not a problem
*provided* it's harder for a malicious party to retrieve them through a
kernel exploit than through an userspace exploit. And it should be !
Anyway, having the (Linux) kernel clearing memory, buffers, whatever...
as soon as it doesn't need them anymore will probably happen at some
point to prevent most leak.
Regards.
--
Yann Droneaud
OPTEYA
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
