Wednesday, May 21, 2014

LibreSSL porting update

I've recently covered some issues with LibreSSL and some common porting mistakes.

Since these articles came out, I've noticed two broken ports I saw prior seem to have vanished. One port has seen significant improvement in response to these articles, although still has significant concerns. And worst of all, more ports are popping up.

The official team has since reiterated some of these concerns, and I also wrote two articles regarding some concerns with random data.

Unfortunately, many of these ports are continuing to rely on arc4random() implementations on certain OSs or from certain portability libraries. These OSs or libraries may be copying some or all of the code from OpenBSD, but they are not copying the implementation.

To demonstrate this, let's see how different implementations of arc4random() work across fork() using the following test code:

Blogger is refusing to allow me to list the headers without trying to escape the signs.
So they are: stdio.h, stdlib.h, stdint.h, unistd.h, sys/wait.h
And on Linux: bsd/stdlib.h

int main()
  int children = 3;
  pid_t pid = getpid();

  printf("parent process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());

  while (children--)
    pid_t pid = fork();
    if (pid > 0) //Parent
      waitpid(pid, 0, 0);
    else if (pid == 0) //Child
      pid = getpid();
      printf(" child process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());
    else //Error
  printf("parent process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());


OpenBSD (the reference implementation):
parent process 0000660d: beb04672 aa183dd0
 child process 00001a2a: e52e0b25 764966bb
 child process 00007eb7: 27619dd1 a7c0df81
 child process 000039f5: 33daf1f1 4524c6c6
parent process 0000660d: 1eb05b45 d3956c43
Linux with libbsd 0.6:
parent process 000031cb: 2bcaaa9a 01532d3f
 child process 000031cc: 3b43383f 4fbbb4d5
 child process 000031cd: 3b43383f 4fbbb4d5
 child process 000031ce: 3b43383f 4fbbb4d5
parent process 000031cb: 3b43383f 4fbbb4d5
 NetBSD 6.1.2:
parent process 0000021a: 4bc81424 958bf90f
 child process 0000021f: c0681a36 5a3f8bdb
 child process 00000022: c0681a36 5a3f8bdb
 child process 000001fc: c0681a36 5a3f8bdb
parent process 0000021a: c0681a36 5a3f8bdb
FreeBSD 9.2:
parent process 0000032e: 03d19ad2 543c5fa4
 child process 0000032f: 6e3a1214 57b74381
 child process 00000330: 6e3a1214 57b74381
 child process 00000331: 6e3a1214 57b74381
parent process 0000032e: 6e3a1214 57b74381
DragonFlyBSD 3.4.3:
parent process 0000030a: cb987922 8f94fb58
 child process 0000030b: 65047965 1ebdc52b
 child process 0000030c: 65047965 1ebdc52b
 child process 0000030d: 65047965 1ebdc52b
parent process 0000030a: 65047965 1ebdc52b

So in looking at this data, one can see that on OpenBSD the random data is utterly different between the parent and all the various children. However, in all the ports of the function, the parent and children all share the exact same state after the fork() call. This situation is fine for single-process programs, but is a disaster in multi-process ones.

Since LibreSSL is having its random needs all being supplied by arc4random*(), and it can be used by multi-process servers, there is a serious porting problem here.

I covered this problem without elaboration in my previous article. See there for some solutions. The OpenBSD team is saying randomness is the responsibility of the OS, and for many of the issues involved, they are quite right. However, remember your ports cannot necessarily rely on the random functions provided by your OS. Even if the OSs fix them in future versions, one still has to be mindful of porting to older ones, so ensure your port doesn't rely too much on the OS.


zdw said...

Just an FYI - it appears to work correctly on OS X:

parent process 0000038b: e7ac9715 8eecdd17
child process 0000038c: e7ed4b63 77516582
child process 0000038d: 4bec9c8d 3e782fd9
child process 0000038e: e0910fc3 10a951b0
parent process 0000038b: 83ba6281 970b07d5

Brendan MacDonell said...

For FreeBSD (libbsd via FreeBSD) at least, the problem is that they ARE derived from the OpenBSD implementation. Unfortunately, they haven't pulled upstream changes since the fork fix went into OpenBSD in 2003.

In the case of FreeBSD and NetBSD, this seems to be because of (unfounded) concerns with the performance of getpid() (Someone should probably poke them and get them to update.) In the case of libbsd, this seems to be something the authors don't know about, so I'll try to push it upstream.

Brad said...

Whether FreeBSD is using an implementation that was derived from OpenBSD's implementation or not is NOT the issue. It is whether the implementation they're using mimics the same behavior as the CURRENT implementation within OpenBSD, not an implementation from 11 years ago.

akmal niazi khan said...

This blog awesome and i learn a lot about programming from here.The best thing about this blog is that you doing from beginning to experts level.

Love from