OpenBSD security features: Difference between revisions

Revision as of 17:23, 28 October 2017

Revision as of 13:57, 27 January 2018

Line 8:

Bugs and security flaws are often caused by programmer error. A common source of error is the misuse of the <code>[[strcpy]]</code> and <code>[[strcat]]</code> [[String (computer science)|string]] functions in the [[C programming language|C]] programming language. There are two common alternatives, <code>[[strncpy]]</code> and <code>[[strncat]]</code>, but they can be difficult to understand and easy to misuse,<ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man3/strncpy.3|title=strncpy – copy part of a string to another|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref><ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man3/strncat.3|title=strncat – concatenate a string with part of another|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref> so OpenBSD developers [[Todd C. Miller]] and [[Theo de Raadt]] designed the <code>[[strlcpy]]</code> and <code>[[strlcat]]</code> functions.<ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man3/strlcat.3|title=strlcpy, strlcat – size-bounded string copying and concatenation|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref> These functions are intended to make it harder for programmers to accidentally leave buffers unterminated or allow them to be overflowed.<ref>{{cite conference |url=http://www.usenix.org/events/usenix99/millert.html |title=strlcpy and strlcat&nbsp;- Consistent, Safe, String Copy and Concatenation |last1=Miller |first1=Todd C. |last2=de Raadt |first2=Theo |author-link2=Theo de Raadt |date=June 6, 1999 |conference=[[USENIX]] Annual Technical Conference |___location=Monterey, California |accessdate=May 26, 2016}}</ref> They have been adopted by the NetBSD and FreeBSD projects but not by the [[GNU C Library]].<ref>{{cite mailing list |url=https://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.html |title=Re: PATCH: safe string copy and concatenation |date=August 8, 2000 |accessdate=May 26, 2016 |mailing-list=[e-mail] |last=Drepper |first=Ulrich}}</ref>

On OpenBSD, the [[Linker (computing)|linker]] has been changed to issue a warning when [[C standard library#Buffer overflow vulnerabilities|unsafe string manipulation functions]], such as <code>strcpy</code>, <code>strcat</code>, or <code>[[sprintf]]</code>, are found. All occurrences of these functions in the OpenBSD source tree have been replaced.{{citation needed|reason=This is probably in their FAQ, or at least on the mailing lists (probably tech@)|date=May 2016}} In addition, a [[Static code analysis|static bounds checker]] is included in OpenBSD in an attempt to find other common programming mistakes at compile time.<ref>{{cite mailing list |url=https://marc.info/?l=openbsd-cvs&m=105665219927976 |title=CVS: cvs.openbsd.org: src |date=June 26, 2003 |accessdate=March 31, 2013 |mailing-list=openbsd-cvs |last=Madhavapeddy |first=Anil }}</ref> Other security-related [[Application programming interface|APIs]] developed by the OpenBSD project include <code>issetugid</code><ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man2/issetugid.2|title=issetugid – is current executable running setuid or setgid|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref> and <code>[[RC4#RC4-based random number generators|arc4random]]</code>.<ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man3/arc4random.3|title=arc4random, arc4random_buf, arc4random_uniform – random number generator|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref>

== Memory protection ==

Line 19:

OpenBSD 3.4 introduced [[W^X]], a memory management scheme to ensure that memory is either writable or executable, but never both, which provides another layer of protection against buffer overflows. While this is relatively easy to implement on a platform like [[x86-64]], which has hardware support for the [[NX bit]], OpenBSD is one of the few OSes to support this on the generic i386 platform,<ref>{{Cite web|url=http://www.openbsd.org/58.html|title=OpenBSD 5.8|website=OpenBSD|access-date=May 28, 2016|quote=Support for the NX (No-eXecute) bit on i386, resulting in much better W^X enforcement in userland for hardware that has this feature.}}</ref> which lacks built in per-page execute controls.

During the development cycle of the 3.8 release, changes were made to the <code>[[malloc]]</code> memory management functions. In traditional Unix operating systems, <code>malloc</code> allocates more memory by extending the Unix data segment, a practice that has made it difficult to implement strong protection against security problems.{{vague|date=May 2016}} The <code>malloc</code> implementation now in OpenBSD makes use of the <code>[[mmap]]</code> system call, which was modified so that it returns random memory addresses and ensures that different areas are not mapped next to each other. In addition, allocation of small blocks in shared areas are now randomized and the <code>free</code> function was changed to return memory to the kernel immediately rather than leaving it mapped into the process. A number of additional, optional checks were also added to aid in development.{{citation needed|reason=IIRC, this is mentioned in the malloc.conf man page|date=May 2016}} These features make program bugs easier to detect and harder to exploit: instead of memory being corrupted or an invalid access being ignored, they often result in a [[SIGSEGV|segmentation fault]] and abortion of the process. This has brought to light several issues with software running on OpenBSD 3.8, particularly with programs reading beyond the start or end of a buffer, a type of bug that would previously not be detected directly but can now cause an error.{{Citation needed|date=May 2016}} These abilities took more than three years to implement without considerable performance loss and are similar in goals to that of the [[Electric Fence]] <code>malloc</code> debugging library by [[Bruce Perens]].

== Cryptography and randomization ==

Line 29:

==X11==

All parts of X11 on OpenBSD are running as the user, except for the X server, which is split between a privilege-stripped X process run as root, and an X process run as the _X11 user. {{citation needed|reason=Checked by Freenode IRC users, need additional source |date=October 2017}}

In X11 on OpenBSD, neither the X server nor X clients normally have any escalated direct memory or hardware privileges: When driving X with the Intel(4) or Radeon(4) drivers, these normally interact with the underlying hardware via the Direct Rendering Management(4) kernel interface only, so that lowlevel memory/hardware access is handled solely by the kernel. Other drivers such as WSFB follow a similar pattern. For this reason, X11 on OpenBSD does not open up lowlevel memory or hardware access to user/root programs as is done on some other systems, and as was done in the past, which then needed the user to escalate the machdep.allowaperture setting from its default zero setting, to an unsecure setting.{{citation needed|reason=Needs additional verification, discussed on chat forums|date=October 2017}}

OpenBSD's version of the [[X Window System]] (named [[Xenocara]]) has some security modifications. The [[X.Org Server|server]] and some of the default applications are patched to make use of [[privilege separation]], and OpenBSD provides an "aperture" driver to limit X's access to memory.<ref>{{Cite web|url=http://man.openbsd.org/OpenBSD-5.9/man4/xf86.4|title=xf86 – X Window System aperture driver|website=OpenBSD manual pages|access-date=May 26, 2016}}</ref> However, after work on X security flaws by Loïc Duflot, Theo de Raadt commented that the aperture driver was merely "the best we can do" and that X "violates all the security models you will hear of in a university class."<ref>{{cite mailing list |url=https://marc.info/?l=openbsd-misc&m=114738577123893&w=2 |title=Re: security bug in x86 hardware (thanks to X WIndows) |date=May 11, 2006 |accessdate=May 26, 2016 |mailing-list=openbsd-misc |last=de Raadt |first=Theo |authorlink=Theo de Raadt }}</ref> He went on to castigate X developers for "taking their time at solving this > 10-year-old problem." On November 29, 2006, a [[VESA BIOS Extensions|VESA]] kernel driver was developed that permitted X to run, albeit more slowly, without the use of the aperture driver.<ref>{{cite mailing list |url=https://marc.info/?l=openbsd-cvs&m=116483366219125&w=2 |title=CVS: cvs.openbsd.org: XF4 |date=November 29, 2006 |accessdate=May 26, 2016 |mailing-list=openbsd-cvs |last=Herrb |first=Matthieu }}</ref>