-fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

hunterthomson · 2013-11-15 10:11:21

I mean really? Even "Ubuntu" has PIE, everyone dose the PaX guys invented ALSR, or were the first to do it..... *no it dose not*
https://wiki.ubuntu.com/Security/Features
________________________________________________________________________

/etc/makepkg.conf use to ship with -fPIC -fPIE compile flags. But I just noticed that they are not their anymore.

Are they like on by default in gcc now or something? Not only dose the vanilla Linux kernel support some memory protections but I use Pax and packages not complied with this capability are very insecure.

I must be missing something....

EDIT: Make sure you read older posts in this thread. I'm not going to edit 'most' of my incorrect statements. I'll leave them for context, but I posted in Newbie Corner for a reason, I am far from knowledgeable at this level of computer operating systems.

Last edited by hunterthomson (2013-11-29 11:18:29)

karol · 2013-11-15 10:24:22

When was that?
https://projects.archlinux.org/svntogit … d8f65a6906 for pacman 3.3.3 doesn't have them, so unless they were added and then removed somewhere between then and now, the change happened ages ago.

hunterthomson · 2013-11-15 10:35:07

Well yes the change could have happened like 2 years ago for all i know.

However, they are still critical compile flags. Without them you have no Position Independent Code and no Position Independent Executables.

Because default Linux kernel supports some this now, I can imagine that these are default ON now in gcc. Or that when you enable other security features like D_FORTIFY_SOURCE they get turned on automatically.

Last edited by hunterthomson (2013-11-15 10:37:49)

karol · 2013-11-15 10:41:02

pacman 3.3.3-4 is 3.5 years old and doesn't have them.
pacman 3.3.0-3 is over 4 years old and doesn't have them.

I found e.g. https://bugs.archlinux.org/task/30010 or https://bugs.archlinux.org/task/28498 but they deal with particular packages, not with makepkg defaults.

Allan · 2013-11-15 10:41:07

It was never enabled.

hunterthomson · 2013-11-15 20:17:40

Right on. I must have put those in my makepkg a long time ago and forgot how they got there

After some more digging through text, it seems PIC should not be enabled globally. I'm still searching around for PIE. I found may links about distro's making it a gcc default, such as Debian and ChromeOS but I didn't spend time to see if they actually did. I know at leas some of the packages were compiled with it. Shoot, there are a number of programs that will not run unless I disable MPROTECT , so they must have PIE capable code.. well incapable, but if they were not compiled correctly they would run fine because PaX would do nothing. I am supper happy that it seems everything is compiled with Stack Smashing Protection (SSP)

However, the 'one' problem with grsecurity + PaX is that the documentation sucks.... well it is just outdated. I just want to make sure these very nice looking paxtest results actually apply to the programs I am running.

ftp://ftp.myrelay.net/linux/paxtest-results

Last edited by hunterthomson (2013-11-15 20:22:06)

hunterthomson · 2013-11-16 08:16:00

Hum ya...., this is not good at all..... Well frack it, I simply can not sand to use any OS other then Arch Linux.

I'm going to rebuild all the Arch packages with/and a Hardened Tool-chain. I'll just start with the Tool-chain first, then what ever I have to, to get OpenSSL, Apache, Nginx, vsFTPD, ... oh ya, and OpenVPN hardened. If I can accomplish that, then I think I'll know by then if I can rebuild a whole DE stack...or at least OpenBox. Gees, how could I forget Postfix and Dovecot

I'm going to rent like 2-4 of those $5 dual-core KVM VPS's form that DigitalOceani that is sponsoring LINUX Unplugged show and just make them burn the CPU's into ash 24/7

#########################################
                OpenSSH
#########################################
~/scratch>>> cat hardening-check_sshd   Fri 15  9:53PM
sshd:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
        unprotected: memcpy
        unprotected: memmove
        unprotected: getgroups
        unprotected: fgets
        unprotected: read
        unprotected: gethostname
        unprotected: strncpy
        unprotected: poll
        unprotected: memset
        unprotected: readlink
        unprotected: snprintf
        unprotected: getcwd
        protected: fprintf
        protected: memcpy
        protected: memmove
        protected: vasprintf
        protected: printf
        protected: read
        protected: realpath
        protected: asprintf
        protected: vsnprintf
        protected: syslog
        protected: fdelt
        protected: poll
        protected: snprintf
 Read-only relocations: yes
 Immediate binding: no, not found!
#########################################
                FireFox
#########################################
~/scratch>>> cat hardeing-check_firefox                   Fri 15  9:53PM
firefox:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
        unprotected: strncpy
        unprotected: strcpy
        unprotected: memmove
        unprotected: fgets
        unprotected: readlink
        unprotected: realpath
        unprotected: memset
        unprotected: read
        unprotected: memcpy
        unprotected: snprintf
        protected: sprintf
        protected: fprintf
        protected: vfprintf
        protected: vsnprintf
        protected: strcat
        protected: memcpy
        protected: snprintf
 Read-only relocations: yes
 Immediate binding: no, not found!
#########################################
                Xorg
#########################################
/usr/bin/Xorg:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
        unprotected: strncpy
        unprotected: memset
        unprotected: strcat
        unprotected: memcpy
        unprotected: fread
        unprotected: stpcpy
        unprotected: fgets
        unprotected: memmove
        unprotected: gethostname
        unprotected: strcpy
        unprotected: snprintf
        unprotected: strncat
        unprotected: read
        protected: memset
        protected: printf
        protected: sprintf
        protected: memcpy
        protected: stpcpy
        protected: fdelt
        protected: memmove
        protected: strcpy
        protected: asprintf
        protected: snprintf
        protected: fprintf
        protected: read
        protected: vsnprintf
        protected: vasprintf
 Read-only relocations: yes
 Immediate binding: no, not found!

Last edited by hunterthomson (2013-11-16 11:51:46)

hunterthomson · 2013-11-16 09:07:28

Would it be "possible" to just steal the "Gentoo Hardened/Toolchain"?

Then start recompiling Arch with it? Like ya, I know every-other package will need significant modification to the PKGBUILD but.... like It should be possible right? I suppose... well no, like I'll be rebuilding Everything so there would not be a problem with upstream-arch being on a different version of GCC or glibc. Ya?

Like, it's all the same stuff. GCC + Kernel + glibc + binutils ~= any Linux distro. So like the only diffrence between distros is just..

file-system layout.
init system
package system
and... that's kind of it right? Well I guess now Ubuntu will have a different Display server.

But like, if that is the case... then I don't see how Gentoo's Hardened/Toolchain would in anyway be unable to build the Archlinux world?

Am I just an idiot?

I do know this is going to take a bunch of work but, well this is what I want and think it is worth my time. Shoot.... well, maybe I 'should' just like switch to hardened gentoo right now. Then working from a complete working implementation of the environment I want to create, start building Archlinux mark two.

Downside... I may loose my drive to harden Arch, if it is no longer a critical; priority #1 job
Upside ... If I have any questions on how things work together I can just look at how my current system is setup.

Last edited by hunterthomson (2013-11-16 09:27:40)

hunterthomson · 2013-11-16 10:37:22

You know..... I think I just need to do some more learning

It seems now that SSP is really the only thing that needs to be done at compile time, and Arch Has a bit of SSP. MPROTECT and all that is enforced ether way. But ASLR, now that I still am kind of sure also has to be done at both coding and compile time. But from what I understand, in order to do ASLR the compiled code needs to be setup for it so the code itself dose not request an address it just requests a function.

But ya, if it is Only ASLR that is disabled, but all this other stuff is still enabled, meh not so bad.

Last edited by hunterthomson (2013-11-16 10:39:32)

karol · 2013-11-16 11:46:31

When posting configs, code or command output, please use [ code ] tags https://bbs.archlinux.org/help.php#bbcode

like this

It makes the code more readable and - in case of longer listings - more convenient to scroll through.

hunterthomson · 2013-11-16 11:52:02

owe shoot, sorry about that.

kang · 2013-11-19 07:45:50

Code needs to be relocatable in memory for ASLR to work. For this, executable binaries have to be compiled "like libraries" (which are relocatable). This is what PIE does (it stands for Position Independent Executable).

ASLR works "by default" with any remotely recent kernel as long as the binaries are compiled with PIE.

I think ArchLinux should enable PIE "by default" or at least "in a maximum amount of packages" on x86-64 since the performance hit is insignificant. I know some people who refuse to use Arch because of this ;-)

Note that ASLR is really only useful if the full binary can be randomized, so that means the linker as well, and it means some more linker flags too.

I think FORTIFY_SOURCE is also missing. SSP (canaries) is there tho.

Finally, it may sound logical that packages add these options instead of the distribution. Unfortunately in the real world many upstream packages don't even know about these options and are unlikely to even take patches (even if it just works). That's probably why major distros (Ubuntu, Fedora, etc.) just enable them everywhere themselves.

hunterthomson · 2013-11-25 13:20:43

Ya this is kind of a big deal. Our only option is to recompile the tool chain with hardened fags (now standard settings on seemingly all other disro's). Then rebuild the the rest of the OS. Ideally, just steal the tool chain from Gentoo Or, just switch to Gentoo.

I say Gentoo because it's the closest comparison to Arch, and it seems to be the premier platform for grsecurity and PaX... kind of like the reference implementation. The Debian guys seem to have their head in the game as well.

I'm just going to have to move to Gentoo. I would really love to stay on Arch; I've been here for 5 1/2 Years

Luckily, I thin partitioned my install of Arch, so I can just create new lv's for Gentoo and install most of it from a fully functional laptop.

hunterthomson · 2013-11-25 13:27:50

It dose 'sound like?' RANDEXEC will do some randomization of executables which were not compiled correctly. It just seems strange that the PaX Team guy keeps talking about it in the past tense

Re: Is there any way to force PIE?
Postby PaX Team » Sat Sep 07, 2013 2:16 pm
RANDEXEC was a kernel-only approach to accomplish a similar effect to what randomizing the load address of a PIE binary has - all without actually having to build a PIE. so RANDEXEC didn't 'force PIE', it worked with normal ELF executables and it really wasn't the best way to accomplish executable randomization and existed mostly to prove that it was possible to do it at all. so no, there's no other way, if you want to randomize the executables as well, build them as PIE.

However, Arch dose a number of other things which prevent it's users from properly securing their OS. The most obvious is putting the "Privileged" binaries in the same directory as non-privileged binaries.

ln -s /usr/bin /sbin

This opens the door for all kinds of attacks, because it is now impossible to disallow non-privileged programs from having access to the file-system which contains things like `su` or any suid/guid'ed binary. Or even if they had read permissions they would not have write permissions if you were able to mount them on a different file-system. That would prevent Hard Links to privileged binaries.

Last edited by hunterthomson (2013-11-29 10:57:24)

cfr · 2013-11-26 02:48:11

In that case, Fedora is also terribly insecure. While Fedora has /usr/sbin as well as /usr/bin, it does not separate privileged binaries in the way you say is essential:

$ l /usr/bin | grep rws
-rwsr-xr-x.   1 root root     2.2M Tach 13 07:30 Xorg*
-rwsr-xr-x.   1 root root      53K Chw  11  2013 at*
-rwsr-xr-x.   1 root root      63K Maw  19  2013 chage*
-rws--x--x.   1 root root      24K Med  10 10:35 chfn*
-rws--x--x.   1 root root      24K Med  10 10:35 chsh*
-rwsr-xr-x.   1 root root      57K Med  26 16:37 crontab*
-rwsr-xr-x.   1 root root      35K Gor   6 05:25 fusermount*
-rwsr-xr-x.   1 root root      77K Maw  19  2013 gpasswd*
-rwsr-xr-x.   1 root root      44K Med  10 10:35 mount*
-rwsr-xr-x.   1 root root      37K Maw  19  2013 newgrp*
-rwsr-xr-x.   1 root root      28K Meh  22 01:51 passwd*
-rwsr-xr-x.   1 root root      23K Med  18 19:30 pkexec*
-rwsr-xr-x.   1 root root      50K Mai  21  2013 pmount*
-rwsr-xr-x.   1 root root      36K Mai  21  2013 pumount*
-rwsr-xr-x.   1 root root      32K Med  10 10:35 su*
-rwsr-xr-x.   1 root root      32K Med  10 10:35 umount*

So you cannot disallow unprivileged binaries from access to these by putting /usr/sbin on a different file system.

Stebalien · 2013-11-26 15:51:10

The hardened-cc package from the AUR works fairly well as a hardened GCC wrapper. To build a hardened package, just run:

CC=/usr/bin/hgcc CXX=/usr/bin/hg++ makepkg

However, it would be nice if (a) arch provided a "hardened" makepkg option that hardened packages automatically and (b) arch actually used it on at least some security sensitive packages.

falconindy · 2013-11-26 19:26:42

hunterthomson wrote:

This opens the door for all kinds of attacks, because it is now impossible to disallow non-privileged programs from having access to the file-system which contains things like `su` or any suid/guid'ed binary. Or even if they had read permissions they would not have write permissions if you were able to mount them on a different file-system. That would prevent Hard Links to privileged binaries.

Mount the partition with nosuid.

Your tinfoil hat seems to be rather snugly fitted.

Mr.Elendig · 2013-11-26 19:56:28

If you are this worried about security, why are you using a distro that doesn't security audit ALL THE THINGS(tm) before they enter the repositories?

As a sidenote on fedora: You can enforce SElinux on it, it even comes with almost usable rules out of the box.

Last edited by Mr.Elendig (2013-11-26 19:56:44)

Stebalien · 2013-11-26 21:52:44

Unfortunately, distros like Fedora are complex and do things behind your back. Complexity and surprise are really bad from a security standpoint. While I would never try to understand an entire Fedora server, I understand my Arch server completely; I know what all the running services do and why they are running because I told my server to run them (I can't say the same thing about other distros).

Also, SELinux is nice but generic MACs have their limitations precisely because they are generic. Trained MACs (configured on a per-server basis), such as Tomoyo, tend to be more secure as they can be tailored to a specific configuration. That is, a generic MAC will need to allow a confined program to do everything it should be able to do in any configuration; a trained MAC will only need to allow a confined program to do what it needs to do in a specific configuration.

Allan · 2013-11-26 21:53:54

Looking at https://wiki.debian.org/Hardening , the things we don't do that Debian hardening does are:

-Wformat -Wformat-security: This is the upstream developers job, and it should pass to all distributions if one distribution deals with it properly.

gcc -pie -fPIE: These (in combination with using -fPIC on shared libraries) are awful to implement by default CFLAGS. Hardened gentoo adjusts the compiler to add them in the right place (-fPIE when generating .o files, -pie when linking them to a binary) - we will not be doing that. If there is a good way to add it for x86_64, it will be considered. Never on i686 (~5-10% performance penalty).

Finally, no "Arch simply has no ASLR support" in the title is wrong: and "even Ubuntu has PIE" is just misleading.

$ cat /proc/sys/kernel/randomize_va_space
2

So that looks like our kernel has ASLR support... Now go to the link provided in the first post: https://wiki.ubuntu.com/Security/Features . Scroll down to "Built as PIE" and note it is a very, very select package set that does it. I know at least some of them build with PIE by default, because that is what the upstream developer does. So what portion of those are not PIE on Arch?

hunterthomson wrote:

Am I just an idiot?

Maybe just uninformed?

Now if the security campaign was directed at replacing -fstack-protector with -fstack-protector-strong, that would be something to consider.

cfr · 2013-11-27 01:25:08

Mr.Elendig wrote:

As a sidenote on fedora: You can enforce SElinux on it, it even comes with almost usable rules out of the box.

It is enabled by default, in fact. You have to disable enforcement if you don't want it.

My only point about Fedora was that it shows that distros which separate /usr/bin from /usr/sbin have do not necessarily have any security benefit over Arch if that benefit is supposed to be based on the case made in this thread.

I don't know enough to know whether the other points are valid or not. I found them hypothetically alarming so tried to do the only check I could think of, which undermined the only point I understood. Doesn't prove the others are invalid but at least casts doubt on the reliability of their source.

EDIT: No idea what -fstack-protector-strong does either but I'd probably sign up for the campaign on the basis of the previous post.

Last edited by cfr (2013-11-27 01:26:54)

hunterthomson · 2013-11-29 14:53:11

I will test the hardened-cc package. I did see that but then I forgot it.

-fstack-protector-strong
Sure, now that seems like a reasonable thing to suggest. From what I read should cause few problems if any, and tries to be wasteful.

Ya, from what I read no one recommends enabling the piePIE, picPIC flags by default. It seems that these are kind of a case-by-case thing, which is a lot to ask. If I find a scriptable way to identify default compatible packages, I'll suggest that. It's just that Arch is "So Close" to being an excellent platform to harden with grsecurity.

Uninformed, I agree.
This is new ground for me, but this is the next step. I've already taken the time to...

use full grsecurity/PaX restrictions, TPE, AIDE, proper white-listing etc/sudoers, restrict bin/su, GPG, LUKS/dm-crypt, VPN, Self Hosted/no cloud services, restrict /sys & /proc, chroot all server daemons.....
Not that I need all that for my protection, but once you get locked into serious security practices, the tendency is to push it as far as you can.

Here begins kind of too long of a post,
but... I wrote it and well don't want it to go to waste.

http://grsecurity.net/the_case_for_grsecurity.pdf
http://grsecurity.net/rbac_tutorial.pptx

Yes, Fedora dose combined sbin and bin. I think they did it before Arch. I didn't mean to say it
was a major problem, nor dose it prevent a script from reorganized things but this configuration
dose not lend it self to security. Perhaps you would like to give vsFTPD CAP_CHROOT and run as
user “rftpd”. That way it can chroot user's but not have full-root. However, it could create a
chroot in which you put a backdoored libc and hard link a suid 0 binary. But, it could not
hard-link to another file-system, right? From a broader perspective, path separation allows for
easy implantation of more restrictive policies, and easier auditing. Like mounting ro 550, and
log all executions from here. Then enabling stricter policies like nosuid to /usr/bin, but don't
spam the logs.

Yes, Red Hat and seemingly 'to me' … most people think SELinux to be the best security solution
for Linux. While it is true that SELinux has expanded beyond it's original purpose, a MAC
implementation, by adding things like more memory protections. It is largely an Access Control
System. Access Control, in many scenarios, is not suppose to prevent exploitation, but instead
mitigate damage. However, even in the context of a MAC solution it … well sucks. I say that if
only because it is far to complicated to implement. Therefor it is most likely incorrectly
implemented, or disabled completely. Also, because labels are a bad idea slow. They cause a
~10% hit on Apache, backup problems, and add complexity.

Grsecurity on the other hand, has RBACwhich matches on inode + full-path, ~1% hit, and
configured by human-readable system-specific auto-generated text files. The more significant
difference is that it makes a valiant effort to prevent exploitation of the kernel and user-land
from occurring in the first place. More significant then that the project is developed by very
smart guys who publish new vulnerabilities and are involved in that community. Like, I read a
post on the full-disclosure mailing about a local privilege escalation vulnerability in the Linux USB driver.
Sure enough a new grsecurity patch was released which included a kernel option to disable USB mounting, as a stop
gap until it's fixed. Being out of the main-line kernel enables grsecurity patch security problems
like this asap, instead of ~10 weeks

Last edited by hunterthomson (2013-11-30 02:28:29)

cfr · 2013-11-30 01:55:58

Why did you put that in code tags?

My point was that Fedora separates bin from sbin but not in a way which allows you to implement the security you mentioned. So Fedora is no more secure for having separate sbin and bin than Arch is for not, even if you are 100% correct about the theoretical possibilities separating them offers. Your post suggested that Arch was uniquely insecure because it combined those directories. If the reason for that is the one you gave, it applies equally to Fedora even though Fedora has separate directories because Fedora installs commands in ways which would make it impossible to implement the hardening step you mentioned. So even if you are right (and I just have no idea about that), Arch is no less secure than other Linux distros (at least Fedora) for combining sbin and bin.

Indeed, I believe that this fact was adduced in the discussions I read on the mailing list about the move to combine those directories. That is, that any theoretical security advantage was purely theoretical and of no practical benefit whatsoever because of the way those directories are actually used.

hunterthomson · 2013-11-30 04:37:51

Well, the code tags made it smaller. I also thought they implied reading it was not required to understand the point of the post. I think it was far to ranty and pointless. But, I'm a ranty kind of guy, so why try to fight it

I am Not suggesting Arch do a 180 and revert this change. That would be a crazy thing to do at this point. I do not expect Arch to bend over backwards to implement security features which the vast majority will not benefit from. On the other hand, if there are choices which would improve the security of everyones system I do suggest those choices be made.

-fstack-protector-strong Seems to be a perfect example of such a choice. Everyone would benefit, and `sed -i 's/-fstack-protector/-fstack-protector-strong/g' is all that is needed to do it. Everyone would benefit from enabling Position Independence as well. However, implementing it seems like a non-trivial task, to say the least (it seems, to me, as of this date/time).

SSP and ASLR are far more important. Directory segregation is merely an added benefit to help justify giving up Arch, which is a nearly perfect OS..... boy that is why I would really rather just take the time to rebuild it from Gentoo's Hardened tool chain.... I'm just not sure I want to go it alone. Man... that would be just such in ideal grsecurity Hardened Linux OS... arg.... Once finals are over..... 5 1/2 years is a hell of a lot of inertia to overcome.

Anyway, I think Red Hat's idea's about how to secure a Linux operating system are fundamentally wrong <removed back-porting and SELinux rant>. So, I don't really care much about what they do or don't do. In any case, sbin directories are where all the system maintenance and/or administrative binaries should be located; /* should contain the core system files needed to boot; /usr/* is where user program files should be; and /usr/local/* should contain self installed/written program files.

The security benefits of mounting all administrative binaries read-only and only viewable by the root user is not theoretical. Nor is the benefit gained by easily identifying anomalies and security breaches. Running AIDE is stupid simple, but knowing for sure what should not have changed is hard. The same goes for knowing what programs should not have been executed. I am positive that almost no one takes advantage of this. I understand why Arch did what it did, and I'm sure it is the best way to accomplish their goals. Unfortunately, from a hardening perspective unified directories introduce far more complexity then they eliminate.

...
Just to clarify, I wrote this and this is how my systems are using sudo + more restrictions that were getting out of the scope of a sudo wiki page.
https://wiki.archlinux.org/index.php/Su … do_Example

Last edited by hunterthomson (2013-11-30 04:56:13)

cfr · 2013-12-01 03:40:46

Is ls a system administration tool or a user programme?

Arch Linux

#1 2013-11-15 10:11:21

-fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#2 2013-11-15 10:24:22

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#3 2013-11-15 10:35:07

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#4 2013-11-15 10:41:02

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#5 2013-11-15 10:41:07

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#6 2013-11-15 20:17:40

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#7 2013-11-16 08:16:00

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#8 2013-11-16 09:07:28

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#9 2013-11-16 10:37:22

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#10 2013-11-16 11:46:31

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#11 2013-11-16 11:52:02

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#12 2013-11-19 07:45:50

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#13 2013-11-25 13:20:43

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#14 2013-11-25 13:27:50

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#15 2013-11-26 02:48:11

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#16 2013-11-26 15:51:10

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#17 2013-11-26 19:26:42

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#18 2013-11-26 19:56:28

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#19 2013-11-26 21:52:44

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#20 2013-11-26 21:53:54

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#21 2013-11-27 01:25:08

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#22 2013-11-29 14:53:11

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#23 2013-11-30 01:55:58

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#24 2013-11-30 04:37:51

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

#25 2013-12-01 03:40:46

Re: -fPIC -fPIE why are they gone? No Arch simply has no ASLR support?

Board footer