File: README.security

package info (click to toggle)
dietlibc 0.34~cvs20160606-10
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 11,336 kB
  • sloc: ansic: 71,631; asm: 13,006; cpp: 1,860; makefile: 799; sh: 292; perl: 62
file content (30 lines) | stat: -rw-r--r-- 1,515 bytes parent folder | download | duplicates (9)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
The diet libc is not especially focused on providing a secure
environment, but where it is possible to do something, we try to do it.

  1. WANT_STACKGAP in dietfeatures.h
     This will randomize the stack layout slightly.  The real memory
     cost is about one page of real memory.  The code size increase is
     about 100 bytes, 86 for i386.  The benefit is that buffer overflow
     exploits are harder because the address of the buffer fluctuates.

  2. WANT_CRYPT_MD5 in dietfeatures.h
     This will enable MD5 style passwords in crypt(3).  The standard
     Unix password mechanism is DES based and thus insecure by today's
     standards.  Adding MD5 makes the code larger by some 5k.

  3. WANT_NON_COMPLIANT_STRNCAT in dietfeatures.h
     strncat and strncpy are very user unfriendly.  They copy zero
     terminated strings, and you can give them a limit on how much to
     copy, but they will not make sure the result is zero terminated,
     which most programmers would expect who are not familiar with the
     API.  So, in the diet libc you can set this #define in
     dietfeatures.h to get the expected behaviour.  Since the fix for
     the normal behaviour usually is to write \0 over the last byte of
     the buffer, this does not hurt usually (but is not standards
     compliant).

  4. printf does not support %n.
     %n in printf is the attack vector for format string
     vulnerabilities.  Almost nobody uses it anyway (except some part of
     the gcc build process, apparently).