# Stack Protector (PaX) for FreeBSD



## bryn1u (Jan 11, 2013)

Hi.

I'm going to make other server with full ssh options for users. I was wondering, is in freebsd FreeBSD any protector against buffer overflow and performance against malware (exploits etc.)? I was reading official user's lists about this thread. SSP has implemented since FreeBSD 8.0 but only for base system! How problem looks with softwares ports/package? Is there any implemented SSP or something like that? I'm trying find some information about PaX (equivalent stack protector in grsecurity). I can't find any information about this problem, why is that such dead topic when is very important? Yes *I* know about MAC, TrusteBSD etc. but it's not a solution to my problem.

Greetings.


----------



## oops (Jan 12, 2013)

There was a similar thread: Thread 20381. Since then FreeBSD grew support for the following

```
$ sysctl -da | fgrep stack
kern.elf64.nxstack: ELF64: enable non-executable stack
kern.elf32.nxstack: ELF32: enable non-executable stack
security.bsd.stack_guard_page: Insert stack guard page ahead of the growable segments.
```


----------



## bryn1u (Jan 12, 2013)

Thanks a lot for replay. I have another question. Are these options work under jail?


----------



## fbsd1 (Jan 15, 2013)

Yes. Because those options run on the host, and all jails use the host's kernel.


----------



## bryn1u (Jan 16, 2013)

Ok. I found any solusion:

*Activar ASLR, PIE, RELRO, NX-Stack y hardening en FreeBSD*

1)

```
[root@reki ~]# cd /usr/ports/net/cvsup
[root@reki /usr/ports/net/cvsup]# make install clean
```
2)

```
cat > /root/RELENG_9-supfile
*default host=cvsup11.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_9
*default delete use-rel-suffix
*default compress

ports-all
src-all
```
3)

```
[root@reki ~]# cvsup -g -L2 /root/RELENG_9-supfile
```
4)

```
[root@reki ~]# fetch http://lists.freebsd.org/pipermail/freebsd-current/attachments/20111116/...
[root@reki ~]# cd /usr/src
[root@reki /usr/src]# patch -p1 < /root/randomize-stack-and-mmap.bin
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|commit 779a962519e7ead63dda24348b98f6cde8156752
|Author: Oliver Pinter
|Date: Tue Oct 4 00:24:01 2011 +0200
|
| forwardport mmap-randomization patch from 7-STABLE-op
|
| Signed-off-by: Oliver Pinter
|
|diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
|index fe01142..dc66db6 100644
|--- a/sys/kern/kern_exec.c
|+++ b/sys/kern/kern_exec.c
--------------------------
Patching file sys/kern/kern_exec.c using Plan A...
Hunk #1 succeeded at 107 (offset 1 line).
Hunk #2 succeeded at 122 (offset 1 line).
Hunk #3 succeeded at 182 (offset 1 line).
Hunk #4 succeeded at 1274 (offset -2 lines).
Hunk #5 succeeded at 1295 (offset 1 line).
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
|index e85b681..991a37d 100644
|--- a/sys/vm/vm_mmap.c
|+++ b/sys/vm/vm_mmap.c
--------------------------
Patching file sys/vm/vm_mmap.c using Plan A...
Hunk #1 succeeded at 68.
Hunk #2 succeeded at 101 (offset 1 line).
Hunk #3 succeeded at 260 (offset -1 lines).
Hunk #4 succeeded at 272 (offset 1 line).
done
[root@reki /usr/src]#
```
5)

```
[root@reki ~]# cat /etc/make.conf
CPUTYPE?=               core2

# Comment from -fomit-frame-pointer to kernel compiling
CFLAGS=                 -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
COPTFLAGS=              -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer -funroll-loops -ffast-math # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
CXXFLAGS+=              -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer -funroll-loops -ffast-math # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie

FORCE_MAKE_JOBS=        yes
MAKE_JOBS_NUMBER=       3
KERNCONF=               BSD GENERIC

OPTIMIZED_CFLAGS=       YES
WITHOUT_X11=            YES
BUILD_OPTIMIZED=        YES
WITH_CPUFLAGS=          YES
WITH_OPTIMIZED_CFLAGS=  YES
WITHOUT_DEBUG=          YES
BUILD_STATIC=           YES
NO_PROFILE=             YES

CC=                     clang
CXX=                    clang++
CPP=                    clang-cpp

NO_WERROR=
WERROR=
NO_FSCHG=

# added by use.perl 2012-06-08 14:22:50
PERL_VERSION=5.10.1
```
6)

```
[root@reki /usr/src]# vi sys/amd64/conf/GENERIC
```
7)

```
[root@reki /usr/src]# make installkernel
```
8)

```
cat >> /etc/sysctl.conf
kern.elf64.nxstack=1
kern.elf32.nxstack=1
```
8.1)

```
[root@reki /usr/src]# make -j4 buildworld
[root@reki /usr/src]# make installworld
```
9)

```
[root@reki ~]# uname -a
FreeBSD reki 8.2-STABLE FreeBSD 9.0-STABLE #1: Thu Jul 19 19:01:37 CEST 2012 root@reki:/usr/obj/usr/src/sys/GENERIC amd64
```
10)
Test if ALSR working as should be:


```
[capi_x@reki ~]$ cat > kk.c
#include

int main() {
float pp;
char kk[256];

printf("%p\n", &pp);
printf("%p\n", kk);

return(0);
}
^D
[capi_x@reki ~]$ clang -fstack-protector -fPIE -pie kk.c -o kk
[capi_x@reki ~]$ ./kk
0x7fffffff70b0
0x7fffffff7040
[capi_x@reki ~]$ ./kk
0x7fffffff9bf0
0x7fffffff9b80
[capi_x@reki ~]$
```

Works well !

Patch works very well on FreeBSD 10.0-current either !


----------



## SirDice (Jan 16, 2013)

bryn1u said:
			
		

> ```
> [root@reki ~]# cd /usr/ports/net/cvsup
> [root@reki /usr/ports/net/cvsup]# make install clean
> ```


Use csup(1) instead. Better yet, drop CVS completely and use devel/subversion.



> ```
> [root@reki ~]# cat /etc/make.conf
> # Comment from -fomit-frame-pointer to kernel compiling
> CFLAGS=                 -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
> ...


Remove these, they'll do more harm than good.



> ```
> [root@reki /usr/src]# make installkernel
> ```


What about *make installworld* and mergemaster(8)?



> ```
> [root@reki ~]# uname -a
> FreeBSD reki 8.2-STABLE FreeBSD 9.0-STABLE #1: Thu Jul 19 19:01:37 CEST 2012 root@reki:/usr/obj/usr/src/sys/GENERIC amd64
> ```


This doesn't look good. Note the different version strings. It's supposed to look like this:

```
dice@williscorto:~> uname -a
FreeBSD williscorto.dicelan.home 9.1-STABLE FreeBSD 9.1-STABLE #0: Thu Jan 10 03:47:34 CET 2013     root@molly.dicelan.home:/usr/obj/usr/src/sys/GENERIC  amd64
```


----------



## bryn1u (Jan 16, 2013)

```
[root@reki ~]# cat /etc/make.conf
# Comment from -fomit-frame-pointer to kernel compiling
CFLAGS=                 -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
COPTFLAGS=              -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer -funroll-loops -ffast-math # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
CXXFLAGS+=              -O3 -pipe -fno-strict-aliasing -fstack-protector -fomit-frame-pointer -funroll-loops -ffast-math # -Wl,-z,relro -Wl,-z,now -D_FORTIFY_SOURCE=2 -fPIE -pie
```

Soo u say that's better dont use it. I've added 8.1 point, missed 2 lines. I took pattern (duplicated) from http://www.haibane.org/node/11
And you right, end of description doesn't seem to be convincing, mean these: 
	
	



```
FreeBSD reki 8.2-STABLE FreeBSD 9.0-STABLE
```
. This shows that the author has two systems in one, really nice.


----------



## francis (Jan 16, 2013)

Hi *bryn1u*. I think that *SirDice* is right writing about removing CXX/CO/CFLAGS from /etc/make.conf file. These settings/values can harm your system, really. Let's move on. You asked about FreeBSD, protector, buffer overflow etc. From my own experience, the FreeBSD has stack protected on some binaries etc. 

Today I wanted to check for You a few binaries (of course not all available in the FreeBSD!) with simple - let say - hardflag-check script. I checked a few binaries, such as, for example; /usr/bin/su, /usr/bin/ssh, /usr/bin/password etc. I was pleasantly surprised, because most tested binaries have had a stack protector. Of course, not all, but... So, maybe some examples

`# ./hardflag-check /usr/bin/ssh`

```
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: no, not found!
Read-only relocations: no, not found!
Immediate binding: no, not found!
```

`# ./hardflag-check /usr/bin/passwd`

```
Stack protected: yes
the rest of hardening features: no, not found etc.
```

`# ./hardflag-check /usr/bin/su`

```
Stack protected: no, not found!
the rest of hardening features: no, not found etc.
```

`# ./hardflag-check /usr/sbin/wpa_supplicant`

```
Stack protected: yes
the rest of hardening features: no, not found etc.
```

`# ./hardflag-check /bin/chflags`

```
Stack protected: no, not found!
the rest of hardening features: no, not found etc.
```

As you can see, not all binaries have stack protection, but most - I hope - have. In these examples, we can also see some drawbacks. The first checking binary /usr/bin/ssh has full informations. I mean also notes - no, not found etc. - about Position Independent Executable (this can protects against "return-to-text" and generally frustrates memory corruption attacks), Fortify Source functions (enable several compile-time and run-time protections in glibc), Immediate binding etc. 

These features are really important from the security point of view. Most of you probably know, how required they are *--* security features, which on all tested binaries have had the same output: no, not found! and no, normal executable! I hope, it will be changed as soon as possible, because I think it is a long-awaited improvements.

So Mr *bryn1u*. As you can see, by default FreeBSD offers some stack smash protection. One more thing; paranoid website is very interesting and contains informations about PROPOLICE for FreeBSD, but described are only two old versions: 5.4 and 6.0, but there is still something to learn, right? I hope, that I helped you in some way. 

By the way; I would like, to show you one more result of already mentioned script, called hardflag-check. However this time, checked will be /sbin/unix_chkpwd binary from the Linux distribution, which I'm running from time to time.

`# ./hardflag-check /sbin/unix_chkpwd` 

```
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes
Read-only relocations: yes
Immediate binding: no, not found!
```

Looks pretty nice. Best regards!


----------



## bryn1u (Jan 16, 2013)

Ooo really nice post . Thanks you for replay. Yes I know that FreeBSD has implemented SSP since FBSD 8.0, but it's only for base system. As you wrote /usr/bin/su, /usr/sbin/passwd etc. These binary files are part of base system yes? Yes. I was wondering what's going on with software coming from ports? Will they build with SSP when I would install example: irssi? *cd /usr/ports/chinese/irssi; make install clean*. It will be installed with stack protection?

Many unix admins had added in FreeBSD 8.0 under options to make.conf:

```
CFLAGS=-fstack-protector-all
CXXFLAGS=-fstack-protector-all
```

why?


----------



## francis (Jan 18, 2013)

Hello, *bryn1u* that's a good question. For sure an nVIDIA graphics card driver is compiled with -fstack-protector option. I do not know whether the installed programs from Ports Collection also support so-called SSP. Certainly few, but all? Frankly, this is very interesting. I will check it out when I find some free time. You also asked about /usr/bin/su, /usr/sbin/passwd binaries. Since they are available after a clean installation, so they should (must) be a part of the base system, right?

*o* *Important Note*: 
Adobe Flash Player has been updated to the 11.2.202.261 version due to several security issue, which could cause a crash and potentially allow an attacker to take control of the affected system. Previous vulnerable version: 11.2.202.258. On VuXML website, which is documenting security issues in FreeBSD and the FreeBSD Ports Collection, last entry related to the linux-flashplugin is dated on 2012-12-14, while the new security update has been released on January 8, 2013. Here is the official security bulletin: APSB13-01 and Common Vulnerabilities and Exposures note - CVE-2013-0630. Installed version can be checked here: About. Please update!

Best regards!


----------



## m6tt (Jan 19, 2013)

SSP/ProPolice works on most ports if you add the cflags (don't do this globally, it's considered dangerous) to the port's Makefile. A global override *WILL* break buildworld. There may be "approved" solutions that allow you to handle this more automatically without making a global override. I've never had a problem with SSP/ProPolice on ports lately.


----------



## bryn1u (Jan 31, 2013)

Hey.

Could you give an example how to add SSP cflags to Makefile ?. I was trying but without results (

Greetings.


----------



## m6tt (Feb 1, 2013)

Depends on the port, but tacking this in there somewhere:


```
CFLAGS+=-fstack-protector-all
```

might work. Watch the code output.

BTW everyone, isn't PaX differnt than ProPolice, i.e. I was under the impression that it is an additional patch against the Linux kernel?


----------



## bryn1u (Feb 1, 2013)

m6tt said:
			
		

> Depends on the port, but tacking this in there somewhere:
> 
> 
> ```
> ...



But what about CLANG ? will working too ?

Many solutions from grsec/PaX are implemented in kernel. PaX doesn't let run any exploits which is very good unlike FreeBSD. FreeBSD has a jail but it;s not resolve a problem using exploits. I don't want to get into inside my server fbsd by using some malware. Jail it's not enough, it only separate from host mother but what in defensing case against malware or if somebody could get access by these hacks ? I don't want to let that happen ! I;m writing many documentations but * I CAN NOT !* find anything about this problem.

I have been using also gentoo-hardened server:

```
bryn1u # ./checksec.sh --proc-all
* System-wide ASLR: PaX ASLR enabled

* Does the CPU support NX: Yes

         COMMAND    PID RELRO             STACK CANARY           NX/PaX        PIE
            init      1 Full RELRO        Canary found           PaX enabled   PIE enabled
           udevd   1142 Full RELRO        Canary found           PaX enabled   PIE enabled
           udevd   1149 Full RELRO        Canary found           PaX enabled   PIE enabled
            sshd   1745 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1801 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1802 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1803 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1804 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1805 Full RELRO        Canary found           PaX enabled   PIE enabled
          agetty   1806 Full RELRO        Canary found           PaX enabled   PIE enabled
            sshd   8470 Full RELRO        Canary found           PaX enabled   PIE enabled
            sshd   8473 Full RELRO        Canary found           PaX enabled   PIE enabled
            bash   8474 Full RELRO        Canary found           PaX enabled   PIE enabled
              su   8479 Full RELRO        Canary found           PaX enabled   PIE enabled
            bash   8480 Full RELRO        Canary found           PaX enabled   PIE enabled
           udevd    981 Full RELRO        Canary found           PaX enabled   PIE enabled
```

Kernel:


```
bryn1u # ./checksec.sh --kernel
* Kernel protection information:

  Description - List the status of kernel protection mechanisms. Rather than
  inspect kernel mechanisms that may aid in the prevention of exploitation of
  userspace processes, this option lists the status of kernel configuration
  options that harden the kernel itself against attack.

  Kernel config: /usr/src/linux/.config

  Warning: The config on disk may not represent running kernel config!

  GCC stack protector support:            Disabled
  Strict user copy checks:                Disabled
  Enforce read-only kernel data:          Disabled
  Restrict /dev/mem access:               Enabled
  Restrict /dev/kmem access:              Enabled

* grsecurity / PaX: Custom GRKERNSEC

  Non-executable kernel pages:            Enabled
  Prevent userspace pointer deref:        Enabled
  Prevent kobject refcount overflow:      Enabled
  Bounds check heap object copies:        Enabled
  Disable writing to kmem/mem/port:       Enabled
  Disable privileged I/O:                 Enabled
  Harden module auto-loading:             Enabled
  Hide kernel symbols:                    Enabled
```

These options are using by grsec that's why thery are disable into kernel:
GCC stack protector support:            Disabled
Strict user copy checks:                Disabled

Im looking for something solutions like up for fbsd but as i said can't find nothing.

Greetings.


----------



## kpa (Feb 1, 2013)

> PaX doesn't let run any exploits which is very good unlike FreeBSD. FreeBSD has a jail but it;s not resolve a problem using exploits.



Show some references that validate your claims. Now you're just repeating hearsay and unverified claims that FreeBSD does not offer any protection agaisnt stack overflow exploits.

Not finding information is not proof that there is a problem, you haven't asked in the right places. Try the mailing lists where the FreeBSD developers are found much more often than here on the forums.


----------



## bryn1u (Feb 1, 2013)

kpa said:
			
		

> Show some references that validate your claims. Now you're just repeating hearsay and unverified claims that FreeBSD does not offer any protection agaisnt stack overflow exploits.
> 
> Not finding information is not proof that there is a problem, you haven't asked in the right places. Try the mailing lists where the FreeBSD developers are found much more often than here on the forums.




Say that Im' only asking. I'm little angry becouse i can't find anything informations . Maybe you know same answers ? FreeBSD has been offering stack protection since FreeBSD 8.0 in base system, i mentioned in earlier posts.  I din't say that haven't got any protections. 

I'm gonna ask on mailing lists. Conclusion i think that solutions should be described in handbook not only in mailing lists if exists.


----------



## xibo (Feb 1, 2013)

bryn1u said:
			
		

> Ok. I found any solusion:
> 
> 
> ```
> ...



Something looks quite bad about that output though: Local variables are allocated on the address-decrementing stack section, therefore it should be kk+256 = &pp if there are no magic cookies interleaved. However, with that output there are *less* than 256 bytes/chars between kk and &pp, which means kk will have less array elements than are specified in kk's declaration, resulting in almost certain (and hard to detect) overflow instead.
The virtual memory addresses not being equal on the second execution also is very strange.


----------



## jlh (Apr 17, 2013)

Hi,



			
				xibo said:
			
		

> Something looks quite bad about that output though: Local variables are allocated on the address-decrementing stack section, therefore it should be kk+256 = &pp if there are no magic cookies interleaved. However, with that output there are *less* than 256 bytes/chars between kk and &pp, which means kk will have less array elements than are specified in kk's declaration, resulting in almost certain (and hard to detect) overflow instead.
> The virtual memory addresses not being equal on the second execution also is very strange.



When -fstack-protector is used, the compilers rearranges the frames's local variables so as to have arrays above the other variables, so an overflow in an array cannot change the execution flow by incidently altering a scalar variable.

The addresses in the second run are not the same because this is a PIE executable.  This is the whole point of a PIE executable: it can be loaded at a different address each time.

-- Jeremie


----------



## ta0kira (Apr 27, 2013)

jlh said:
			
		

> When -fstack-protector is used, the compilers rearranges the frames's local variables so as to have arrays above the other variables, so an overflow in an array cannot change the execution flow by incidently altering a scalar variable.


If you look at the output though, kk+256-&pp=144, which means filling kk will overwrite pp. If you add this line:
	
	



```
printf("%li\n", (long) (kk + sizeof kk - (char*) &pp));
```
then it should print a value <=0 or >=sizeof pp+256 regardless of the order of kk and pp on the stack. The output in question indicates that this isn't the case, though.

Kevin Barry


----------



## interfasys (Feb 18, 2014)

Patches have been published to add fstack-protector-strong to ports. Once lang/gcc48 has been compiled, you can add this to your make.conf:

```
WITH_SSP_PORTS=YES
SSP_CFLAGS=-fstack-protector-strong --param ssp-buffer-size=4
```

http://www.freebsd.org/cgi/query-pr.cgi?pr=186852


----------



## bryn1u (Feb 18, 2014)

interfasys said:
			
		

> Patches have been published to add
> fstack-protector-strong to ports. Once lang/gcc48 has been compiled, you can add this to your Makefile:
> 
> ```
> ...



hi, 

Thanks for your replay but what about clang. FreeBSD 10 has default clang compiler. This role in make.conf will work 
with clang or is enough to add with_ssp = yes to make.conf ?

greetz,


----------



## interfasys (Feb 18, 2014)

Clang does not support "-fstack-protector-strong" yet, but the other options should be available.


----------



## bryn1u (May 4, 2014)

interfasys said:
			
		

> Clang does not support "-fstack-protector-strong" yet, but the other options should be available.



For Clang in FreeBSD 10 is this is good role ?

/etc/make.conf

```
WITH_SSP_PORTS=YES

SSP_CFLAGS=-fstack-protector-all --param ssp-buffer-size=4
SSP_CXXFLAGS=-fstack-protector-all --param ssp-buffer-size=4
```

if not, why ?

P.S
Does Clang have a fstack protector strong feature ? or still doesn't ?

Greetz,


----------



## xibo (May 4, 2014)

bryn1u said:
			
		

> interfasys said:
> 
> 
> 
> ...


stack-protector-all means that any procedures independent of it's local storage size will get it's overflow detection cookies, so the ssp-buffer-size is ignored.
Also, SSP_CXXFLAGS is not considered, c++ uses CFLAGS here.



			
				bryn1u said:
			
		

> P.S
> Does Clang have a fstack protector strong feature ? or still doesn't ?
> 
> Greetz,


The clang in base does not have stack-protector-strong. I wouldn't consider this much too tragic though, as stack-protector-strong just a compromise to achieve better performance than stack-protector-all does, while reducing coverage.


----------



## bryn1u (May 4, 2014)

Thank you for reply. I'm grateful.


----------



## bryn1u (May 14, 2014)

Very similar topic: viewtopic.php?f=3&t=46435


----------

