Date: Mon, 2 Apr 2012 16:02:12 -0400 From: Richard Yao <ryao@cs.stonybrook.edu> To: Peter Wemm <peter@wemm.org> Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules Message-ID: <4F7A05C4.9070808@cs.stonybrook.edu> In-Reply-To: <CAGE5yCrz45AWeJGv=2UWRq7xpXZVtvsx%2B5O6cvaE6ZzoFrz5mA@mail.gmail.com> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <CAGE5yCpuvsVrc-%2BDTVas-W4fjuP2s%2B6PQONMOTyEbGnj2CY3ig@mail.gmail.com> <4F766F29.2030803@cs.stonybrook.edu> <CAFHbX1KiZx68MP4bCAvPc0Zui3fA4O35_z3kP781zoJqLYp7Bw@mail.gmail.com> <4F79D88B.3040102@cs.stonybrook.edu> <CAFHbX1KE15G9gx7Duw2R8zC5jL1jiEir0yMB0-s5%2B4xx517WtQ@mail.gmail.com> <4F79E27E.3000509@cs.stonybrook.edu> <CAGE5yCrwLosuTT2yq0DEx%2Bz8ztKpkrB=tORmURcuh_SCz=L7qg@mail.gmail.com> <4F79FCB8.1090003@cs.stonybrook.edu> <CAGE5yCrz45AWeJGv=2UWRq7xpXZVtvsx%2B5O6cvaE6ZzoFrz5mA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------enigCE81F30EC81A02BB7386186E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 04/02/12 15:37, Peter Wemm wrote: > On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao <ryao@cs.stonybrook.edu> w= rote: >> On 04/02/12 14:46, Peter Wemm wrote: >>> Remember.. ASLR is a userland thing. .ko files, which is what this >>> thread is about, already use random address layout. When you do a >>> "kldload virtio.ko", you have no way to predict what address it will >>> be loaded at. And you don't even have access to the addresses. >>> >>> Of course if you want to talk about ASLR and userland .so files then >>> that's an entirely different thing. But this thread is about your >>> tools finding DT_TEXTREL in a .ko kernel file, not userland .so files= =2E >>> >> >> The PaX project's patches to the Linux kernel include kernel stack >> randomization. The Gentoo Hardened project makes use of this in their >> fork of the Linux kernel. >> >=20 > I looked at their code, and their description here: > http://pax.grsecurity.net/docs/randkstack.txt >=20 > Of note: > "pax_randomize_kstack() gathers entropy from the rdtsc instruction > (read time stamp counter) and applies it to bits 2-6 of the kernel > stack pointer. This means that 5 bits are randomized providing a > maximum shift of 128 bytes - this was deemed safe enough to not cause > kernel stack overflows yet give enough randomness to deter > guessing/brute forcing attempts." >=20 > This has nothing to do with the DT_TEXTREL in .ko that this thread is > about and has no bearing on ASLR in any way. There are plenty of techniques employed to do ASLR by both the upstream Linux kernel and the PaX patches to it. I only needed to state one to prove that you were wrong about ASLR being exclusive to userland. If the QA checks had been triggered for an out-of-tree Linux kernel module, the Gentoo developers would consider it to be a bug. I have verified this with the Gentoo Hardened developers. Furthermore, they confirmed that text relocations in out-of-tree kernel modules would negatively affect ASLR. My original email to the list asked if this was an issue in FreeBSD. That question had been answered. However, people went ballistic upon the mere presence of my question, so I assured them that if I ever found time to write exploit code, I would do full disclosure to ensure that this issue was fixed. I stumbled across this issue when setting up an environment in which I could port gptzfsloader to Linux, so I have no reason to implement ASLR in the FreeBSD kernel. Also, the abuse I received over this has lead me to conclude that doing anything for upstream would be deterimental to my mental health, so I am not inclined to try. However, there could be unknown exploits in the wild that would be killed by ASLR in the wild. It would be best for someone, who considers securing FreeBSD to be worth suffering from abuse, to implement it. That person is not me. --------------enigCE81F30EC81A02BB7386186E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPegXHAAoJELFAT5FmjZuExZMQAKteZYCJdHHVHyF9YyJbCgbu eir2tSxJDygBtk58da56ZB5dx0UEW5/IDyLXFLJSLXZz7ZCZItc64WqgMv5zWf1W aAkpwV2g6EP7YEPYXryHPNlEzgpPgUIjkHGOMkDoyFMX6aii7lvz7SboEpArA3ak zuRWk1q9/8FBvAbkcR08DuZZYoVp6p4iBAtOFoWDFOfOkI7gL+3uSIKXHemxRaHX mslVHVLYGtKI7CxUdJW3kXqpV6BElerhbRXR9PHqJhC2Y1VTy7ZmOgpIYMCzWgPI woQk/N9MXcA/XHYmmpzSZEuYCiIpcPID1wdxaMPsz/g6UawFapxzJwiKKvbRjxNF 90BGKrQQncJE0eNzXjK+iSqBDBPMHoWJMSR1h2evKkCzDE37GpDjLOXLRuW/gjjd 5soH0t9mcFfZPRf77IwFHyhOxHF5Jy/wC4JdOXZdjinWK3DWv959P0Gmp/5UUFu6 iT1XAPYEo1D/BIa7kBP0PbLMzuwa4gtdcwspj61TAFsJl0PRBocMSleYoUUBtGOF j6cN0fPuL34eVxq2hEKY3NceTXQwDHeg6zb5I0inKiefDsIqIJeO5v8OsWFGHmqj RO760KhY/gZEAvoQQQOmw373OGllW3NNS4GjYcq9jC5pHYHjmEPsR6J6+VTZKDjf qMurt6yCYl993KOSM6Y0 =XyxY -----END PGP SIGNATURE----- --------------enigCE81F30EC81A02BB7386186E--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F7A05C4.9070808>