Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 23:18, Zac Medico wrote: > > We've got experimental support for FEATURES=xattr since > portage-2.2.0_alpha80. We can include that in the next portage-2.1.x > release. > Awesome. If possible though, let's keep the no-SUID-ever discussion for another thread, as xattr still raises the same point this thread is focused on: if they're not PIE, they can be easily injected, and their "xattr"s utilized for nefarious means. > -- > Thanks, > Zac > >
Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
On Monday 23 January 2012 14:08:51 Jason A. Donenfeld wrote: > So I recently published this: http://blog.zx2c4.com/749 , a local priv > escalation. It doesn't work on Fedora because their /bin/su is compiled > with -pie. (They don't compile gpasswd with -pie though, so they're still > vulnerable.) In any case, what if we made it a policy in Gentoo to compile > * all* SUID binaries with PIE, to prevent against any types of future > attacks of this variety? pedantically, PIE+ASLR makes it significantly harder to exploit, not impossible if we could get some general performance numbers that show non-PIE vs PIE, that'd help make the case for turning PIE on by default regardless of set*id. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Monday 23 January 2012 15:12:47 Francesco Riosa wrote: > 2012/1/23 Mike Gilbert: > > On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld wrote: > >> To check for PIE, > >> > >> readelf -h /bin/su | grep Type > >> > >> If it says EXEC, no PIE. If it says DYN, yes PIE. > > > > I'm asking "how does one enable PIE/ASLR", not how to check if it is > > enabled already. > > - PIE should be -fPIC also for the executable, not only for the .so > (has a performance impact) not entirely sure what you're saying here. i'll clarify in general: - build all code going into shared libraries with -fPIC (regardless of hardening, this is Gentoo policy today) - build code going into executables with -fPIE (this is what hardened does, not default Gentoo systems) you could build all code (including executables) with -fPIC, but that has useless overhead compared to -fPIE. it's small but not insignificant. > - ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help > too the hardened toolchain "helps", but it is not required. ASLR is in the mainline Linux kernel and iirc, enabled by default. it is already operating on all shared libraries because those are PIC. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Monday 23 January 2012 14:37:40 Diego Elio Pettenò wrote: > Il giorno lun, 23/01/2012 alle 20.26 +0100, Jason A. Donenfeld ha scritto: > > When ASLR is turned on, the .text section of executables compiled with > > PIE is given a randomized base address. When ASLR is off or when PIE > > is not used, the base address is predictable, so it's easy to find > > where to write into. > > Yup, I know that. I was just making sure that the actual prevention came > from ASLR and not PIE by itself. Both because there is at least one > sci-math package that cannot build with ASLR (randomize_va_space) turned > on emacs is known to crap itself when building with ASLR too, and the existing workarounds (just like its own build system) tend to be fragile :( -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On 01/23/2012 12:12 PM, Francesco Riosa wrote: > 2012/1/23 Mike Gilbert : >> On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld wrote: >>> To check for PIE, >>> >>> readelf -h /bin/su | grep Type >>> >>> If it says EXEC, no PIE. If it says DYN, yes PIE. >> >> I'm asking "how does one enable PIE/ASLR", not how to check if it is >> enabled already. > > - PIE should be -fPIC also for the executable, not only for the .so > (has a performance impact) > - ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help too > > xattr could be used to reduce the number of suid binaries, but need > support in portage We've got experimental support for FEATURES=xattr since portage-2.2.0_alpha80. We can include that in the next portage-2.1.x release. -- Thanks, Zac
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/23/2012 07:40 PM, Jason A. Donenfeld wrote: > > What I propose is just to /detect/ at merge-time whether or not > there are SUID binaries that are not PIE, and if so, spit out a Q&A > warning. > > That way, package maintainers could fix things up bit by bit, > without having to burden you alone with tinderbox troubles. This actually sounds a great idea. It probably worth opening a feature request for portage using our bugzilla. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPHcePAAoJEPqDWhW0r/LCGvwP/03SWLvj9L7DzWq4hRyvOFUB t0ugAPv+D3xT1dyAY6QarPWAMotfPPk2LTSR2y4yvxqt8mYoW0xablTB9S+V5YSn QbBJOQ+lsWzr0Qv5OcWBWWIeOIdyVfX7eMer9YTD1T+zVVOixU0P9T60zq0F6VmI 7Sk/wmFVmj0Tm3iqS9rWkA6aik5TVTKN4NdjqEoOlyZUqNtdgqnChf3eWlWdK/tK nctze3JRdQdXVcY4q4JHh+cwR099wBL61BzCB9lrwc0HCfKBU3oKrqU29ZjKsDfQ xtOgOmh0pCVuPtbHnVHC+YWGmBpoRuExaDa5PMbCCrQPi/bcQioMa6XaVmkJqJ7M bcj5ArCEuE7+66iUvhjwv2vMyA9Vm5RLCpc7YN7dfLwsT+d/2W6+CtRkr38v+mGd OcFiCfcw3tPoUvZwL+RrAk1rXb3mL4in3XeKwwshq6VjIajKfX29h99YazeZ1X5N WErKapz9t6pdEcfurXMZJb2WeLljKHI9DkRcOXvK9mb4dDbKk20+KeQ646N5pJCS c6pJnoU1R8zXPNeP+xAKvaRslubXNmY6mPfE5Lqmzz0DLYi7BMHjP3Cjx30kc9hz SwiqoEPSdPE4dzQhqP5EGXZkxgUhCu4IaeCWVCh/sP67QZk8dElBJ9nj14w++Kxr CGNbH7oBy5y5vNAd+LCr =glKZ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Monday 23 January 2012 15:00:41 Mike Gilbert wrote: > I'm asking "how does one enable PIE/ASLR", not how to check if it is > enabled already. Just enable hardened profile that compiles generally with: -fno-strict-overflow -fPIE -fstack-protector-all in particular with gcc-hardenednossp you have: fno-strict-overflow -fPIE with gcc-hardenednopie you have: fno-strict-overflow -fstack-protector-all with gcc-hardenednopiessp you have: -fno-strict-overflow -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
2012/1/23 Mike Gilbert : > On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld wrote: >> To check for PIE, >> >> readelf -h /bin/su | grep Type >> >> If it says EXEC, no PIE. If it says DYN, yes PIE. > > I'm asking "how does one enable PIE/ASLR", not how to check if it is > enabled already. - PIE should be -fPIC also for the executable, not only for the .so (has a performance impact) - ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help too xattr could be used to reduce the number of suid binaries, but need support in portage right?
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 03:00:41PM -0500, Mike Gilbert wrote: > I'm asking "how does one enable PIE/ASLR", not how to check if it is > enabled already. Look at http://hardened.gentoo.org, the default toolchain used includes PIE, and it also includes various other measures (like additional grSecurity restrictions or even SELinux) that makes Gentoo Hardened systems less vulnerable to this specific vulnerability. Wkr, Sven Vermeulen
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld wrote: > To check for PIE, > > readelf -h /bin/su | grep Type > > If it says EXEC, no PIE. If it says DYN, yes PIE. I'm asking "how does one enable PIE/ASLR", not how to check if it is enabled already.
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
To check for PIE, readelf -h /bin/su | grep Type If it says EXEC, no PIE. If it says DYN, yes PIE. -- sent from my mobile On 1/23/12, Mike Gilbert wrote: > On Mon, Jan 23, 2012 at 2:40 PM, Jason A. Donenfeld wrote: >> That way, package maintainers could fix things up bit by bit, without >> having >> to burden you alone with tinderbox troubles. > > How do I go about testing with PIE/ASLR on my own box? Is it just some > CFLAGS? > > A link to some documentation would or just a quick set of instructions > would be great. > >
[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
Il giorno lun, 23/01/2012 alle 20.40 +0100, Jason A. Donenfeld ha scritto: > What I propose is just to detect at merge-time whether or not there > are SUID binaries that are not PIE, and if so, spit out a Q&A > warning. > > That way, package maintainers could fix things up bit by bit, without > having to burden you alone with tinderbox troubles. The quick answer is: "you can try but it's not going to happen". It's not something we haven't done before, in relation to suid binaries. For quite a long time we've had the "immediate binding" warning on suid binaries built without -Wl,-z,now — it was removed once both uclibc and glibc took care of forcing immediate bindings at the loader's level for suid binaries, but we've had packages throwing that warning till the very last moment. Even though it was already a warning when _I_ became a dev. Sigh :) -- Diego Elio Pettenò Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 2:40 PM, Jason A. Donenfeld wrote: > That way, package maintainers could fix things up bit by bit, without having > to burden you alone with tinderbox troubles. How do I go about testing with PIE/ASLR on my own box? Is it just some CFLAGS? A link to some documentation would or just a quick set of instructions would be great.
[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 20:37, Diego Elio Pettenò wrote: > > Stripping a compiled file of read permissions is quick, painless and > (mostly) safe from errors. Changing the way it is compiled.. not so > much. > > I'm not saying that it's not a good idea, but if we want to proceed with > this, there has to be someone who goes to look at all the packages and > corrects them. > > Right. It's a big ordeal. I'm *not* suggesting, however, that we automatically inject a CFLAG or something awful like that. What I propose is just to *detect* at merge-time whether or not there are SUID binaries that are not PIE, and if so, spit out a Q&A warning. That way, package maintainers could fix things up bit by bit, without having to burden you alone with tinderbox troubles.
[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
Il giorno lun, 23/01/2012 alle 20.26 +0100, Jason A. Donenfeld ha scritto: > When ASLR is turned on, the .text section of executables compiled with > PIE is given a randomized base address. When ASLR is off or when PIE > is not used, the base address is predictable, so it's easy to find > where to write into. Yup, I know that. I was just making sure that the actual prevention came from ASLR and not PIE by itself. Both because there is at least one sci-math package that cannot build with ASLR (randomize_va_space) turned on, and because it would have disproven my old blog post: http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie > Doesn't portage already have a check on SUID executables where it > checks to see if they meet a certain standard and also strips them of > read capabilities? Couldn't we just add a Q&A blurb to this, so that > if any SUID executables are merged that aren't PIE, there's a nice > yellow warning? And then gradually package maintainers would add the > required patches? Stripping a compiled file of read permissions is quick, painless and (mostly) safe from errors. Changing the way it is compiled.. not so much. I'm not saying that it's not a good idea, but if we want to proceed with this, there has to be someone who goes to look at all the packages and corrects them. I've not been running the tinderbox for a while both because I have very little time to _file_ bugs, but more importantly because, being there to file bugs only, without the time to tackle them, the result was a bunch of grumpy devs who either needed to repeat the test on a new version, as the bug became stale, or found me positively annoying as I didn't fix the stuff myself. That said, I could fix up the tinderbox and make it run again, no problem there. I could even try to find the time to look at the logs and/or see if s3fs allows me to publish them for someone to look through them... and definitely identifying all the packages installing suid binaries is easier than looking through all the logs. But I'd rather not do that unless there is enough consensus that we'll be tackling the issue. -- Diego Elio Pettenò Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
On Mon, Jan 23, 2012 at 20:22, Diego Elio Pettenò wrote: > > Is it because of PIE alone or ASLR? Just curious it doesn't make much > difference to me. > When ASLR is turned on, the .text section of executables compiled with PIE is given a randomized base address. When ASLR is off or when PIE is not used, the base address is predictable, so it's easy to find where to write into. > Here's the trick: it's hard to decide what to compile PIE and what not > because we generally don't split the build for the two. I guess a good > point here could be made to build _everything_ PIE, but it can be tricky > (at least hotot seem not to work on a PIE system). > Doesn't portage already have a check on SUID executables where it checks to see if they meet a certain standard and also strips them of read capabilities? Couldn't we just add a Q&A blurb to this, so that if any SUID executables are merged that aren't PIE, there's a nice yellow warning? And then gradually package maintainers would add the required patches? It would be also a good idea to resume working on the file-based > capabilities, dropping suid altogether. > Of course. But, different discussion.
[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?
Hello Jason, Il giorno lun, 23/01/2012 alle 20.08 +0100, Jason A. Donenfeld ha scritto: > So I recently published this: http://blog.zx2c4.com/749 , a local priv > escalation. I've seen the news :) > It doesn't work on Fedora because their /bin/su is compiled with > -pie. (They don't compile gpasswd with -pie though, so they're still > vulnerable.) Is it because of PIE alone or ASLR? Just curious it doesn't make much difference to me. > In any case, what if we made it a policy in Gentoo to compile all SUID > binaries with PIE, to prevent against any types of future attacks of > this variety? Here's the trick: it's hard to decide what to compile PIE and what not because we generally don't split the build for the two. I guess a good point here could be made to build _everything_ PIE, but it can be tricky (at least hotot seem not to work on a PIE system). It would be also a good idea to resume working on the file-based capabilities, dropping suid altogether. The main issue here: it's not just my call to make; toolchain and council should probably chime in on this. -- Diego Elio Pettenò Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
Hi Diego, So I recently published this: http://blog.zx2c4.com/749 , a local priv escalation. It doesn't work on Fedora because their /bin/su is compiled with -pie. (They don't compile gpasswd with -pie though, so they're still vulnerable.) In any case, what if we made it a policy in Gentoo to compile * all* SUID binaries with PIE, to prevent against any types of future attacks of this variety? Jason
[gentoo-dev] Lastrite: compiz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My apologies for sending this twice to the gentoo-dev ml, but I forgot to CC gentoo-dev-announce. # Jorge Manuel B. S. Vicetto (22 Jan 2012) # Mask compiz for last-rites unless someone steps up # to maintain it. Removal in 30 days. dev-python/compizconfig-python x11-apps/ccsm x11-apps/fusion-icon x11-apps/simple-ccsm x11-libs/compiz-bcop x11-libs/compizconfig-backend-gconf x11-libs/compizconfig-backend-kconfig4 x11-libs/libcompizconfig x11-plugins/compiz-plugins-extra x11-plugins/compiz-plugins-main x11-plugins/compiz-plugins-unsupported x11-themes/emerald-themes x11-wm/compiz x11-wm/compiz-fusion x11-wm/emerald I no longer have the time nor will to work on the desktop-effects packages. In reality they've been unmaintained for quite sometime now. Unless someone steps up, there won't be any alternative to finally remove compiz from the tree. - - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPHSwrAAoJEC8ZTXQF1qEPu7sP/RpXjcPRVmH5vCIs/sdt7Op/ EC9RQ7c616q0jHhLI+Aj86OZqfZG45NtVfprW2kmQO0mtxf/YGq9+W5k4JGhkGn9 sVZkijuETq83VFzm/kHzGFGkGcshX/p5sO+Fd1LMJHfZSuRfds+5JMwx61P7y98A kn/BJwWRc1MbqLxOzte8NdwLpEtmLVom+mjOfA841nLWIfiAe5Fs8mNevOtTr1j1 GU8VX82vWT1Zy1fYT9Vd3KBQRW4yXrKZ9oNhZdwvpbzuBQ4w+TUsfezdLPix624W viyA0L5QdAiOktWL+XsUdcLZHnTG9Huzfl2zuWq8UbtP8K0YpZ2AWWV879peAs2g 4AFJthQ6ZkJr5PrRrX19eZhnPhlrVB8jGo50ZF1L5JGGGZLNFmDfxZWO2d4ZIjS9 sBFDjhUtQSX27nvq/AFhrha3XU4tdfoZGvHQD6GRb9EYjT6OJDhuN5zg09XQG0eX 69AE9shlWG1hD4JVkZbJKljMQJYC/UwToZUZ5Jh/BMD0r8AcX6Aq09FCuaJKqW6y gQUzX+NBSyQn7a7g9qIPzDive+CrES6s5m2nuY6r/3yuhoIGCLiUh+ZAQfq4R1Qd pDcMkRCoUOJUYzx9zR9eiV4wNOqqGb+iWIE0qh+4fWYB4IIrKc48VXlnMviZcaJr FMDp9WHC2BV2kwtUzbUi =2uGL -END PGP SIGNATURE-
