[PATH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS.
Hi,
Following your suggestions here is the patch that fixes the offset2lib issue.
Only s390 architecture is not affected by the offset2lib, the solution for
all the architectures is based on this one, and so the
CONFIG_ARCH_BINFMT_E
On Tue, Dec 23, 2014 at 12:06 PM, Hector Marco Gisbert wrote:
> [PATCH] ASLRv3: inter-mmap ASLR (IM-ASLR).
>
>
> The following is a patch that implements the inter-mmap (IM-ASLR)
> which randomizes all mmaps. All the discussion about the current
> implementation (offset2lib and vdso) shall be solv
[PATCH] ASLRv3: inter-mmap ASLR (IM-ASLR).
The following is a patch that implements the inter-mmap (IM-ASLR)
which randomizes all mmaps. All the discussion about the current
implementation (offset2lib and vdso) shall be solved by fixing
the current implementation (randomize_va_space =2).
While
On Tue, Dec 23, 2014 at 12:07 AM, Reno Robert wrote:
> Hi Andy,
>
> I would like to mention couple of things
>
> 1. With reference to details mentioned in vdso patch, there are ~76 repeated
> address in 1 runs. This may not be good enough. Consider the case of
> local exploitation, one can sti
On Mon, Dec 22, 2014 at 3:23 PM, Hector Marco Gisbert wrote:
>> Before I even *consider* the code, I want to know two things:
>
> >
> > 1. Is there actually a problem in the first place? The vdso
> > randomization in all released kernels is blatantly buggy, but it's
> > fixed in -tip, so it s
Before I even *consider* the code, I want to know two things:
>
> 1. Is there actually a problem in the first place? The vdso
> randomization in all released kernels is blatantly buggy, but it's
> fixed in -tip, so it should be fixed by the time that 3.19-rc2 comes
> out, and the fix is mar
On Mon, Dec 22, 2014 at 12:03 PM, Jiri Kosina wrote:
> On Mon, 22 Dec 2014, Andy Lutomirski wrote:
>
>> It could be worth having a mode that goes all out: randomize every
>> single allocation independently in, say, a 45 or 46-byte range. That
>> would be about as strong ASLR as we could possibly
On Mon, 22 Dec 2014, Andy Lutomirski wrote:
> It could be worth having a mode that goes all out: randomize every
> single allocation independently in, say, a 45 or 46-byte range. That
> would be about as strong ASLR as we could possibly have, it would
> result in guard intervals around mmap data
On Mon, Dec 22, 2014 at 11:49 AM, Jiri Kosina wrote:
> On Mon, 22 Dec 2014, Andy Lutomirski wrote:
>
>> a. With PIE executables, the offset from the executable to the
>> libraries is constant. This is unfortunate when your threat model
>> allows you to learn the executable base address and all yo
On Mon, 22 Dec 2014, Andy Lutomirski wrote:
> a. With PIE executables, the offset from the executable to the
> libraries is constant. This is unfortunate when your threat model
> allows you to learn the executable base address and all your gadgets
> are in shared libraries.
When I was originally
On Mon, Dec 22, 2014 at 9:36 AM, Hector Marco Gisbert wrote:
> [PATH] Randomize properly VVAR/VDSO areas
>
> This is a simple patch to map the VVAR/VDSO areas in the mmap area,
> rather than "close to the stack". Mapping the VVAR/VDSO in the mmap area
> should fix the "VDSO weakness" (too little e
[PATH] Randomize properly VVAR/VDSO areas
This is a simple patch to map the VVAR/VDSO areas in the mmap area,
rather than "close to the stack". Mapping the VVAR/VDSO in the mmap area
should fix the "VDSO weakness" (too little entropy). As I mentioned in a
previous message, this solutions should n
On Fri, Dec 19, 2014 at 2:11 PM, Andy Lutomirski wrote:
> On Fri, Dec 19, 2014 at 2:04 PM, Hector Marco wrote:
>>
>>
>> El 12/12/14 a las 18:17, Andy Lutomirski escribió:
>>
>>> On Dec 12, 2014 8:33 AM, "Hector Marco" wrote:
Hello,
I agree. I don't think a new randomizat
On Fri, Dec 19, 2014 at 02:11:37PM -0800, Andy Lutomirski wrote:
...
> >
> > Therefore, I can fix the current implementation (maintaining the
> > randomize_va_space=2) by moving the PIE executable from the mmap base
> > area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do).
> > But w
On Fri, Dec 19, 2014 at 2:04 PM, Hector Marco wrote:
>
>
> El 12/12/14 a las 18:17, Andy Lutomirski escribió:
>
>> On Dec 12, 2014 8:33 AM, "Hector Marco" wrote:
>>>
>>>
>>> Hello,
>>>
>>> I agree. I don't think a new randomization mode will be needed, just fix
>>> the current randomize_va_space=
El 12/12/14 a las 18:17, Andy Lutomirski escribió:
On Dec 12, 2014 8:33 AM, "Hector Marco" wrote:
Hello,
I agree. I don't think a new randomization mode will be needed, just fix
the current randomize_va_space=2. Said other way: fixing the offset2lib
will not break any current program and so
On Dec 12, 2014 8:33 AM, "Hector Marco" wrote:
>
> Hello,
>
> I agree. I don't think a new randomization mode will be needed, just fix
> the current randomize_va_space=2. Said other way: fixing the offset2lib
> will not break any current program and so, no need to add additional
> configuration op
Hello,
I agree. I don't think a new randomization mode will be needed, just fix
the current randomize_va_space=2. Said other way: fixing the offset2lib
will not break any current program and so, no need to add additional
configuration options. May be we shall wait for some inputs
from the list (ma
Hi,
On Thu, Dec 11, 2014 at 09:12:29PM +0100, Hector Marco wrote:
>
> Hello,
>
> The following is an ASLR PIE implementation summary in order to help to
> decide whether it is better to fix x86*, arm*, and MIPS without adding
> randomize_va_space = 3 or move the PowerPC and the s390 to
> randomi
Hello,
The following is an ASLR PIE implementation summary in order to help to
decide whether it is better to fix x86*, arm*, and MIPS without adding
randomize_va_space = 3 or move the PowerPC and the s390 to
randomize_va_space = 3.
Before any randomization, commit: f057eac (April 2005) the cod
On Mon, Dec 8, 2014 at 12:09 PM, Christian Borntraeger
wrote:
> Am 05.12.2014 um 01:07 schrieb Hector Marco:
>> [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
>>
>> The issue appears on PIE linked executables when all memory areas of
>>
[PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
The issue appears on PIE linked executables when all memory areas of
a process are randomized (randomize_va_space=2). In this case, the
attack "offset2lib" de-randomizes all library areas on 64 bit Linux
syste
Am 05.12.2014 um 01:07 schrieb Hector Marco:
> [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
>
> The issue appears on PIE linked executables when all memory areas of
> a process are randomized (randomize_va_space=2). In this case, the
> attack "offse
On Thu, Dec 4, 2014 at 4:07 PM, Hector Marco wrote:
> [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
>
> The issue appears on PIE linked executables when all memory areas of
> a process are randomized (randomize_va_space=2). In this case, the
> attack
Hi,
Thanks for working on this!
On Thu, Dec 4, 2014 at 4:07 PM, Hector Marco wrote:
> [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
>
> The issue appears on PIE linked executables when all memory areas of
> a process are randomized (randomize_va_space=2).
[PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
The issue appears on PIE linked executables when all memory areas of
a process are randomized (randomize_va_space=2). In this case, the
attack "offset2lib" de-randomizes all library areas on 64 bit Linux
syste
26 matches
Mail list logo
