search for: aslr

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our implementation is based off of PaX's. Oliver Pinter, Danilo Egea, and I have been working h...

Hey All, [NOTE: crossposting between freebsd-current@, freebsd-security@, and freebsd-stable at . Please forgive me if crossposting is frowned upon.] Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology. It helps secure applications against low-level exploits. A popular secure implementation is known as PaX ASLR, which is a third-party patch for Linux. Our implementation is based off of PaX's. Oliver Pinter, Danilo Egea, and I have been working h...

...in CentOS 5. We found out that this is due to the fact that CentOS 5 does randomization of the address space when loading binaries, libraries, and when using mmap, so that is what's causing our problem. The thing is, I'm trying to google for it, but I did not find any useful information on ASLR present in CentOS 5/RHEL 5/Linux 2.6.18. If anyone has any good pointers on reliable information on what does that code do, how to configure/tweak it, or how to use mmap properly to work around the issues, I would really appreciate it. In particular, if there is a switch/option that would allow us...

...r. >> But if there is a syscall (like the one used by setarch) we could call it >> and reexec. >> Using setenv("DYLD_NO_PIE")+reexec looks gross to me. > There's posix_spawnattr_setflags() that can do the job > (http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/), > but the necessary flag appeared only in Lion. > > To the best of my knowledge, there's no link-time option that disables > ASLR but keeps PIE on Snow Leopard or Lion. > At the moment we're using DYLD_NO_PIE with Chromium binaries to > disable ASLR at...

> As for the patch, I really don't like >   1. 3 different cases for 3 different flavors of MacOS. How are we goring > to support it? The first is Leopard, which we don't want to support at all. Maybe we should check that in some other place. The second is Snow Leopard, where ASLR is controlled by the DYLD_NO_PIE env var, which is read by the dynamic loader. The third is Lion, which does not support DYLD_NO_PIE, but instead supports a flag I've mentioned above. I suppose further Mac OS releases will support only this way. There also is the MH_PIE bit in the Mach-O heade...

...xec. This will be a debugging nightmare for us and for users. I would prefer just to print a descriptive warning message and exit: ==123== ERROR: AddressSanitizer on MacOS requires to disable ASRL for the executable. ==123== ERROR: You can do it this way: ==123== ERROR: <how to disable ASLR> ==123== ABORTING --kcc > > >> > Another question: if asan would require -no_pie on Mac, will this be a >> serious limitation? >> > >> >> If asan required no pie on Linux, would it be a serious limitation? >> > > For Linux, I don't...

...really don't like > > 1. 3 different cases for 3 different flavors of MacOS. How are we > goring > > to support it? > The first is Leopard, which we don't want to support at all. Maybe we > should check that in some other place. > The second is Snow Leopard, where ASLR is controlled by the > DYLD_NO_PIE env var, which is read by the dynamic loader. > The third is Lion, which does not support DYLD_NO_PIE, but instead > supports a flag I've mentioned above. I suppose further Mac OS > releases will support only this way. > > There also is the M...

...ime is of course better. > But if there is a syscall (like the one used by setarch) we could call it > and reexec. > Using setenv("DYLD_NO_PIE")+reexec looks gross to me. There's posix_spawnattr_setflags() that can do the job (http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/), but the necessary flag appeared only in Lion. To the best of my knowledge, there's no link-time option that disables ASLR but keeps PIE on Snow Leopard or Lion. At the moment we're using DYLD_NO_PIE with Chromium binaries to disable ASLR at runtime.

On Fri, Dec 9, 2011 at 11:16 AM, Eric Christopher <echristo at apple.com>wrote: > > On Dec 9, 2011, at 11:12 AM, Kostya Serebryany wrote: > > > Yes, we have no ASRL with -no_pie. > > Can we disable ASRL even with -pie? > > On linux we can do it with "setarch x86_64 -R". > > > > You asked about link time. Now it sounds like you're talking

+llvmdev Question to MacOS gurus: is there a way to disable ASLR (address space layout randomization) on Darwin at link time instead of doing setenv("DYLD_NO_PIE", "1", 1); and reexec? Thanks, --kcc On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at google.com>wrote: > The attached patch introduces the disable_aslr op...

Two other things: 1) I get massively more stable execution times on 16.04 than on 14.04 on both x86 and ARM because 16.04 does far fewer gratuitous moves from one core to another, even without explicit pinning. 2) turn off ASLR: "echo 0 > /proc/sys/kernel/randomize_va_space". As well as getting stable addresses for debugging repeatability, it also stabilizes execution time variability due to "random" conflicts in caches, hash collisions in branch prediction or BTB, maybe even uop cache. On Mon, Fe...

...mming (ROP) by > denying the attacker information about the exact code layout. Putting on my security hat (as opposed to my lurking-on-compiler-mailing-lists hat), note that artificial software heterogeneity doesn't actually prevent ROP, it makes it harder in a qualitatively similar way to ASLR. With ASLR, the attacker needs to discover a single memory address in order to construct a return-oriented program. What you're proposing requires reading out more of the address space. A recent paper at Oakland proposed a "just-in-time code reuse" attack that repeatedly uses a memor...

...e and I can not find support for them so before I start trying to use lld I thought I would ask. I have found a couple of cases where they are essential. i.e. where there is no other way to get the required information, such as getting the address of the mach-o headers of the current process, with ASLR enabled, if the process is not dyld as exec on macOS only provides the mach header address to dyld (*1). They are used inside of dyld and I am now using them in “x86_64-xnu-musl”. It’s possible to resolve a mach-o segment offset or a mach-o section offset using these special ld64 linker synthesise...

Hi all- I would like to standardize on a very simple protocol by which a guest OS can obtain an RNG seed early in boot. The main design requirements are: - The interface should be very easy to use. Linux, at least, will want to use it extremely early in boot as part of kernel ASLR. This means that PCI and ACPI will not work. - It should be synchronous. We don't want to delay boot while waiting for a slow host RNG. (On Linux, at least, we have a separate interface for that: virtio-rng. I think that Windows has some support for virtio-rng as well.) - Random numbers...

Hi all- I would like to standardize on a very simple protocol by which a guest OS can obtain an RNG seed early in boot. The main design requirements are: - The interface should be very easy to use. Linux, at least, will want to use it extremely early in boot as part of kernel ASLR. This means that PCI and ACPI will not work. - It should be synchronous. We don't want to delay boot while waiting for a slow host RNG. (On Linux, at least, we have a separate interface for that: virtio-rng. I think that Windows has some support for virtio-rng as well.) - Random numbers...

...rs: FATAL: ThreadSanitizer: unsupported VMA range FATAL: Found 47 - Supported 44 and 46 and FATAL: Code 0x00010eddf660 is out of application range. Non-PIE build? FATAL: MemorySanitizer can not mmap the shadow memory. FATAL: Make sure to compile with -fPIE and to link with -pie. FATAL: Disabling ASLR is known to cause this error. FATAL: If running under GDB, try 'set disable-randomization off'. Obviously something changed when I updated the OS but I am not sure how to fix it. The compilation options didn't change and ASLR isn't disabled. I used the same gcc compiler to buil...

...- bles. -no_pie Do not make a position independent executable (PIE). This is the default, when targeting 10.6 and earlier. On Dec 9, 2011, at 11:02 AM, Kostya Serebryany wrote: > +llvmdev > > Question to MacOS gurus: is there a way to disable ASLR (address space layout randomization) on Darwin at link time > instead of doing setenv("DYLD_NO_PIE", "1", 1); and reexec? > > Thanks, > > --kcc > > On Fri, Dec 9, 2011 at 4:28 AM, Alexander Potapenko <glider at google.com> wrote: > The attach...

...4.14 is > what's presently live on the system. If you want I think you should be able > to replicate that aspect via 'xbps-install linux4.14' (and then of course > booting said kernel). I booted to linux-4.14 and test_kex still passes. Have you twiddled any sysctls related to ASLR or security? -d

...ze on a very simple protocol by which a guest >> OS can obtain an RNG seed early in boot. >> >> The main design requirements are: >> >> - The interface should be very easy to use. Linux, at least, will >> want to use it extremely early in boot as part of kernel ASLR. This >> means that PCI and ACPI will not work. > > How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? > Could hypervisors and simulators simply make sure these work? > If RDRAND is available, then Linux, at least, will use it. The rest are too complic...

...ze on a very simple protocol by which a guest >> OS can obtain an RNG seed early in boot. >> >> The main design requirements are: >> >> - The interface should be very easy to use. Linux, at least, will >> want to use it extremely early in boot as part of kernel ASLR. This >> means that PCI and ACPI will not work. > > How do non-virtual systems get entropy this early? RDRAND/Padlock? Truerand? > Could hypervisors and simulators simply make sure these work? > If RDRAND is available, then Linux, at least, will use it. The rest are too complic...