Am Thu, 9 Jun 2016 09:18:40 +0100
David Chisnall <thera...@freebsd.org> schrieb:

> If this paper is the one that I think it is, then I was one of the reviewers. 
>  Their
> attack is neat, but it depends quite a lot on being able to deterministically 
> trigger
> deduplication.  Their proof-of-concept exploit was on Windows (and JavaScript 
> attack
> was really fun) and I’m not convinced that it would work reliably on Linux or 
> VMWare
> ESX, which both defer deduplication for as long as possible to avoid 
> NUMA-related
> overheads.
> 
> We don’t currently have a FreeBSD implementation, but if someone wanted to 
> provide one
> then a defence against this attack would be fairly simple: count the number 
> of CoW
> faults that a process is receiving and if it reaches a certain threshold then 
> remove
> all of its memory from the set of eligible pages.  The attack relies on being 
> able to
> repeatedly trigger CoW faults and time whether they occur, with the same set 
> of pages.
> At least some existing implementations will make this impossible as these 
> pages will
> repeatedly be deduplicated and then duplicated and this is already a 
> pathological case
> that most memory deduplication implementations need to handle (as well as 
> being a
> security hole, it’s also a big performance killer).
> 
> Kib has been working on ASLR for FreeBSD (I think it’s in 11?), but at this 
> point it’s
> more of a checkbox item than a serious mitigation technique.  It adds a 
> little bit of
> work for attackers, but there are so many attacks that can bypass ASLR even 
> with strong
> entropy that it just increases the work factor slightly.  If you’re running 
> code
> written in C, then you’re better off relying on Capscium compartmentalisation 
> to limit
> what the attacker can do once they’ve compromised it.
> 
> David
> 
> > On 8 Jun 2016, at 16:01, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> > 
> > A couple of days I got as a responsible personell for a couple of systems a 
> > warning
> > about the vulnerabilities of the mechanism called "Kernel SamePage Mergin". 
> > On this
> > year's IEEE symposion there has been submitted a paper by Bosman et al., 
> > 2016,
> > describing an attack on KSM. This technique, also referred to as memory/page
> > deduplication, seems to be vulnerable by design under certain 
> > circumstances. I guess
> > the experts of the readers here do already know, but I consider myself a 
> > non-expert
> > and therefore, I'd like to ask about the status of that kind of development 
> > in
> > FreeBSD. I read about a project of last year's Google Summer of Code 2015 
> > targetting
> > KSM on FreeBSD.
> > 
> > In Linux, this deduplication techniques is implemented since kernel 2.6.38 
> > and Windows
> > Kernel uses this techniques since Windows 8.1 and sibblings (also Windows 
> > Server). We
> > were strongly advised to disable those "features" in Windows clients, 
> > servers and
> > Linux servers, if used.
> > 
> > Other papers describe successful attacks on memory contents and ASLR by 
> > misusing KSM.
> > On Windows, mmap() entropy is 19bit, on Linux usually 28bit. And FreeBSD (if
> > planned/used/already implemented?)? 
> > 
> > If you are interested I could provide links or PDFs of the papers I already 
> > gathered
> > about that subject (it is not much, simply google for "KSM FReeBSD" or KSM
> > deduplication ASLR).
> > 
> > Thanks in advance,
> > 
> > oh  
> 

Hello David,

sorry for the lack of references. 

Bosman et al., 2016: doi: 10.1109/SP.2016.63
(http://www.ieee-security.org/TC/SP2016/papers/0824a987.pdf), this paper has 
been subject
of a warning given to institutions.

An older one, but also interesting, is

Xiao et al., 2013: doi: 10.1109/DSN.2013.6575349
(http://www.cs.wm.edu/~hnw/paper/memdedup.pdf) 

and this one 

Barresi et al., 2015 (https://www.usenix.org/node/191961).

The first paper is of (my) concern, since it triggered some interests and 
couriosities of
mine.

Regards,

Oliver Hartmann

Attachment: pgpAtW88lYTj2.pgp
Description: OpenPGP digital signature

Reply via email to