Planet FreeBSD

I am the current maintainer of OpenSSH for FreeBSD, and have been since 2002. I am also the author and maintainer of the PAM implementation used by FreeBSD, and of several of the accompanying PAM modules. Finally, I was a member of the FreeBSD Security Team for several years, served as Assistant Security Officer and Acting Security Officer, and authored or co-authored around 20 security advisories between 2002 and 2004.

I have been asked to comment on SecurityFocus advisories 7467 and 7482, regarding timing attacks against certain versions of OpenSSH that were distributed with FreeBSD 4.x and 5.x releases.

The short version is that no FreeBSD 4.x or 5.x release was ever vulnerable. Read on for the long version.

The two issues are closely related, albeit not identical. They both allow an attacker to confirm information that they already have, or that they have guessed, and the attack mechanism is roughly the same. In both cases, a different code path is taken depending on the outcome of the authentication process. In the affected versions of OpenSSH, there are three possible outcomes:

1. non-existent user: no attempt to verify password
2. existent user, wrong password: authentication fails
3. existent user, correct password: authentication succeeds

Additionally, the user may be administratively blocked—for instance, if PermitRootLogin is off, root will not be able to log in at all. This is the default in FreeBSD.

An attacker that can distinguish between cases 1 and 2 can verify that a particular user exists on the target system. This is the core of issue 7467.

An attacker that can distinguish between cases 2 and 3, even if they do not ultimately gain access, can verify that a particular password is correct for a particular user on the target system. This is the core of issue 7482.

Outwardly, OpenSSH will behave in the exact same manner in all three cases: if you try to log in as a non-existent user, or as a user that is administratively blocked, you will still be asked for your password.

Internally, however, the code paths are different. In case 1, OpenSSH will not invoke PAM authentication to verify the password provided by the client, since it already knows the outcome. In cases 2 and 3, it will invoke PAM authentication. The attack relies on being able to determine whether PAM authentication was invoked, and whether it was successful, even if you are unable to log in.

Here is the crux of the matter: some operating systems have PAM modules that will delay for two seconds when authentication fails. Therefore:

• An attacker that attempts to log on as a particular user with a made-up password will see a two-second delay after each password prompt if and only if the user exists.
• An attacker that attempts to log on as a user which they know exists, but which is administratively blocked (e.g. root, see above), will see a two-second delay after each password prompt if and only if they typed the wrong password.

FreeBSD's PAM modules do not delay when authentication fails. There will still be minute differences in timing, but they will be too small to measure across the network.

Therefore, FreeBSD is not vulnerable to these attacks.

Finally, I should mention that the first issue was addressed in OpenSSH 3.6.1p2 by invoking PAM authentication even for non-existent users, and the second in OpenSSH 3.9p1 by passing an invalid password to PAM when someone tries to log in as root on a system where RootPermitLogin is off.

[edited for clarity on 2008-08-04]

Instead of trying to describe all the changes regarding layer2 filtering in pf I’d better provide some examples.

Ethernet address can be specified for host or interface name:
pass in on bridge0 from 10.0.0.1 ether 00:11:11:11:11:11 to 10.0.0.2 ether 00:22:22:22:22:22
pass in on bridge0 from ($int_if:network) ether 00:11:11:11:11:11 to any

Ethernet addresses are supported in table entries:
table <test> persist {10.0.0.1 ether 00:11:11:11:11:11, 10.0.0.2 ether 00:22:22:22:22:22}
pass on bridge0 from <test> to <test> keep state (ether)

Ethernet stateful filtering is handled specially. Per rule flag is added to conditionally enable ethernet stateful filtering (disabled by default):
pass log on bridge0 from <test> to <test> keep state (ether)

With keep state (ether) enabled pf uses real source and destination ethernet addresses from the first packet to create the state and uses these addresses afterwards to match the state.

Although FreeBSD/mips has been committed to the tree, a few stragglers haven't been pushed into the tree for various reasons. Oleksandr Tymoshenko and I have been honing them down and have just published a set for review.

If you'd like to try FreeBSD/mips out, you can grab these patches from Oleksandr's directory. There's four diffs included. Please send any feedback to arch@freebsd.org.

In order to get online using GPRS you would need:

1. A device capable of handling GPRS; usually a cell phone or a GPRS modem. I've used a Nokia 3110c with some success. This particular cellphone model offers a USB port using which it may be connected to a host computer with a compatible USB cable.
2. A subscription to GPRS service. Contact your cell service provider on the way to enable this on your cell phone. The examples below describe the configuration needed for using AirTel's GPRS service.
3. The appropriate configuration for your OS. This post describes how to use GPRS using FreeBSD and NetBSD.

FreeBSD Configuration

1. Ensure that the relevant drivers are present in the kernel. The Nokia 3110c is supported by the stock umodem(4) driver. Use kldload(8) to load this into your kernel if it is not already present:

   # kldload umodem
   

2. On connecting the cellphone to the computer, you should see a message similar to the following on the console (or in /var/log/messages):

   ... kernel: ucom0: Nokia Nokia 3110c, rev x.yy/a.bb, addr 2, iclass 2/2
   ... kernel: ucom0: data interface 2, has CM over data, has break
   ... kernel: ucom0: status change notification available
   

   If all goes well, a new device entry such as /dev/cuaU0 should be present under /dev.
3. Add the following to /etc/ppp/ppp.conf (note the leading whitespace on most lines):

   airtel:
    set device /dev/cuaU0
    enable dns
    set phone "*99***1#"
    set authname "airtel"
    set authkey "airtel"
    set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \
     \"\" AT OK-AT-OK ATQ0V1E1S0=0&C1&D2+FCLASS=0 OK \
     AT+CGDCONT=1,\\\"IP\\\",\\\"airtelgprs.com\\\" OK \\dATDT\\T \
     TIMEOUT 40 CONNECT"
     add default HISADDR
     set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
   

   For the curious, the ppp(8) manual page fully describes the syntax and semantics of the configuration commands above.

   Note that the contents of the authname and authkey configuration items do not seem to matter. You could put the name of your pet dog there if you wish.

4. Invoke the ppp(8) daemon in the usual way:

   % ppp airtel
   ppp> dial
   ... the prompt changes as PPP setup progresses
   PPP>
   

   And you should be done.

NetBSD Configuration

In NetBSD as in FreeBSD, this particular cellphone model is supported by the umodem(4) driver. Once recognized, the modem will be accessible using a path name such as /dev/ttyU0.

The following recipe uses the pppd(8) daemon. This recipe requires the NetBSD kernel to have been compiled with in-kernel PPP support.

1. Create a file /etc/ppp/peers/airtel with the following contents:

   ttyU0 115200
   connect '/usr/sbin/chat -v -f /etc/ppp/chat-airtel -T "*99***1#"'
   defaultroute
   usepeerdns
   ipcp-accept-local
   ipcp-accept-remote
   user "airtel"
   password "airtel"
   

2. Create a file /etc/ppp/chat-airtel with the following contents:

   ABORT "BUSY"
   ABORT "NO CARRIER"
   ABORT "ERROR"
   ABORT "NO ANSWER"
   "" "AT"
   OK "ATQ0V1E1S0=0&C1&D2+FCLASS=0"
   OK AT+CGDCONT=1,\"IP\",\"airtelgprs.com\"
   OK \dATDT\T
   TIMEOUT 40
   CONNECT
   

3. Start ppp using:

   # pppd call airtel
   

   Monitor /var/log/messages for error messages.

4. Once the connection is setup, IP addresses for the ISP's DNS servers would be placed in /etc/ppp/resolv.conf. Add these to /etc/resolv.conf if needed.

Connection performance

In my experience, connection speeds vary widely from a few bytes/second to a peak of a few KB/sec. Connection latencies also tend to be variable, ranging from a few hundred milliseconds upwards. There are frequent long pauses, a minute or more in duration, during which no traffic flows (though the connection remains up).

Thus GPRS based connectivity is best used for batch tasks such as downloading and sending email.

I’ve fixed the known issues with BSD grep and rewritten some parts as my mentors suggested. Now I’m waiting for his answer about the current code and if he thinks it’s ok, I’ll submit it to portmgr@ for a thorough test. The last time grep failed on pointyhat due to a bug in -v.

As for BSD diff, I have completed some features, but still there are various to implement. The current status can be seen here.

I finally had some time, a need for wireless connectivity in the shop and found my stash of old Prism 2, 2.5 and 3 cards. I thought I'd try them out with the new vap stuff.

First, there's a new filter on the firmware revisions in the driver. Very old versions of the firmware basically don't work without a lot of coaxing and workarounds. They are no longer supported. In addition, symbol cards are fairly rare and there's no readily available documentation for them, so support for them was removed as well. This filtering is a good thing, since it will keep people from using cards that are known to be broken. However, I had to fix a bug in the interrupt registration to make this work out OK (and to also stop spontaneous panics sometimes on attach if there was a lot of interrupt activity on a shared interrupt). I basically moved the interrupt registration to the end of the attach function, rather than the beginning and solved both problems.

All of these cards that I had don't have new enough firmware to support WPA. This highlights another problem: wpa_supplicant doesn't filter out WPA APs when it is looking for things to attach to, or otherwise provide a meaningful error message that would tell the user the reason that WPA isn't working is that their card is too old/lame to support this new-fangled stuff....

I wound up solving my problem with an atheros card that just worked, once I found them...

Kris has rewritten and optimized various aspects of pointyhat package cluster, making a heavy use of ZFS features like cloning. On amd64, we can now complete a full package build (without openoffice ports) in mere 20 hours. Impressive!

One of the prices paid when I moved out to rural India last year was loss of connectivity.

For many months, there was no reliable way for people to call and reach me. As for internet access, I used to go to the nearby town (20km away) to an internet parlour from where I would access the 'Net---if there was power in the town to do so. Keeping my FreeBSD CVSup repository in sync used to be a interesting challenge, as was keeping up the communication flow with my two GSoC'07 mentees.

Connectivity options began to improve about a month ago: AirTel's cell service started up in the area so I could get online using GPRS. And then, last week, BSNL started offering DSL service in this area.

In the past year I explored various options for getting online as a FreeBSD user; I will describe these here by and by. Stay tuned!

The FreeBSD Foundation has announced binary releases of the JDK 1.6 and JRE 1.6. For more details, see the Foundation newsletter and the download page.

Keith has noted the adventures that we've recently had in the GEM branch with the disagreement between the CPU and GPU about how memory gets addressed. We've got a pretty decent solution now I think, though I'm having some troubles getting the MCHBAR mapped on desktop 965s, so I can't tell what mode the CPU is in. I automatically disable tiling in that case, to avoid broken rendering. Apparently the MCHBAR's locked out so that mortals don't go in and break their memory configuration. But overclockers have figured out how to unlock it, so I'm sure we will figure out as well in due time.

Next project for me is fixing issues with PBO and FBO. While we enabled support for the ARB_framebuffer_objects and ARB_pixel_buffer_objects on 965 with TTM/GEM development, that implementation from the 915 came with a lot of bugs that we haven't got around to fixing. Now as more people are looking to use buffer objects, we need to get those bugs fixed.

The first issue I've found is that we're not flushing batchbuffers full of rendering before mapping buffer objects. This will anger conformance tests that do rendering then read the resulting data out immediately. I wrote up a fix for this today that I'll be testing in the next couple of days.

The second is that we're trying to use the 2d blitter for accelerating copies between buffer objects and the screen. That's things like glReadPixels to a PBO, glDrawPixels from a PBO, glCopyTexSubImage, glCopyPixels with read != draw drawable, etc. The trick is that for buffer objects we render them upside down compared to the shared front and back buffers. So when we're blitting between the two we need to invert the data -- set a negative pitch on one of the buffers and a base address somewhere at the other end. The blitter's supposed to be cool with this. Except that there's this comment in the code:

/* Initial y values don't seem to work with negative pitches. If
* we adjust the offsets manually (below), it seems to work fine.

So we need to not just put the offset somewhere on the other side, but exactly so that y == 0 in the offset we set is the end of the blit area. Combine this with the fact that for tiled buffers the offset has to be 4KB-aligned, and it means that we're probably going to be angering our blitter if you choose unpleasant offsets for the the part of the blit that's in the shared front/back/depth.

I might be able to work around it today by just flipping the buffer that isn't tiled instead, assuming that both aren't tiled. But we want to get to the point of tiling them both. I think the right solution here is to just ditch using the blitter for almost everything. If we figure out how to add meta operations to mesa for these sort of pixel path operations, we could write generic acceleration for anybody who wanted to use it, by mapping them to normal GL operations using texturing. While it's some CPU overhead for state management, the 3D path is supposed to be faster than 2D GPU-wise, and it would get rid of a bunch of metaops code inside of our driver which has proved to be fragile at best.

In the next week I'm hoping to work on getting some metaops set up. Beyond PBO, it would also help us for implementing accelerated SGIS_generate_mipmap, which is currently hurting compiz and other apps, and more complete glBitmap which is hurting mesa demos (and we know how important those are).

have been looking at this program for a while: glfer. though i haven’t been able to get it running.

To test it i’m using a homebrewed magnetics loop antenna with an amp and bp filter.

There were some discussions on hackers@ and current@ about BSD grep, but I haven’t yet written anything about it here, so it’s high time to do so. First, you can see here what I have done. As you see, the list of functions is complete. There is -P (–perl-regexp), which never worked on FreeBSD, but I will try to add this as an optional feature to have a nice and complete grep implementation.

There are some problems, though. GNU accepts non-standard regexes, for example (a|), which has an empty subexpression, while our regex library doesn’t. First, I tried to  workaround these in the code, but as I was pointed out later it broke other cases, thus I had to realize that it was not so easy to fix and I needed to remove those workarounds, thus the problem still persists. I’ve looked at our regex library a bit. It was written by Henry Spencer. He has a new version of his library but that version still has the same behaviour. I’ve been told about the PCRE library, which has a POSIX-compatible interface. I realized that in fact it’s just the interface, the interpretation of the expressions in still Perl-like. Solutions are still needed…

In trying to bring the MIPS tree more into line with idealized FreeBSD practices, I've moved the SoC directories up one level in the hierarchy. Future changes will make it easier to define different boards, as well as stylizing these sorts of things across different CPU architectures. I need this for the Plat'Home OpenMicroServer work I've started on, so I'll use that to drive these changes.

For the curious, I've moved mips/mips32/adm5120 -> mips/adm5120, likewise with the idt, malta, and sentry5 directories. While all of these were, strictly speaking, mips32 CPUs, having them in their own subdirectory doesn't make a lot of sense. There's never going to be so many of them that having an extra layer of indirection is going to help. Also, mips32 is ambiguous. Does it mean the MIPS ISA known as MIPS32 and MIPS32r2? Does it mean that the ports are running in 32-bit mode? It wasn't clear where a 32-bit kernel for a mips64 processor would live. Also, the idt parts aren't completely mips32 compliant in a couple of minor details. Is that non-compliance enough to move them elsewhere?

The next set of changes will try to tease apart the boot loader environment from the SoC that it is running on. While many SoCs have their own bootloader, often times one may also run uboot on the same hardware. In addition, things like uboot are used in many different platforms, so duplicating that code will grow tiresome.

Once the boot loader stuff is better abstracted, the next set of problems will be how to create a system that can run on multiple different boards of the same SoC. At first, this will be statically compiled, but eventually it will be dynamic.

Another key component of this work, whose overall goal is to make it easier to add board support to FreeBSD embedded platforms, will be an overhaul of the hints system. While it can be made to work, there are some practical problems it solves poorly that are desirable to have solved better. For example, it has no good way to tie attributes or parameters to hardware. Today, one can only tie them to a driver instance, which itself can be tied to hardware.

Finally, the last planned component in this work is a simplification of creation of busses with attributes and fixed or semi-fixed children. You can't have variants of hints loaded today that say "If I'm running on a AT91RM9200, use this set, but if I'm runnning on an AT91SAM9620 use this other set of hints" to enumerate the busses. This makes it hard to achieve the dynamic selection of boot code to run needed to allow kernels to boot on a variety of boards.

Most of this is low-level code janitor stuff. However, it is code janitor stuff that's needed and will be important to FreeBSD's success in the future.

There is good news, and bad news, on the bugbusting front.

I think we have made good progress on the state of the PR database recently. In particular, with the help of our recent volunteers attractedby the Bugathons, we have been able to filter the backlog, identifying the majority of the PRs by what manpage they are correlated with (for kern/ PRs, primarily sections 3, 4, and 8 via ‘tags’; for bin/ PRs, primarily sections 1 and 8). There are now prototypes of HTML reports that reports corresponding to each of these. (They are not yet interactive; they run once per day on freefall). Also, all the PRs with patches are now tagged by ‘[patch]‘, and there is an HTML report for those, too. There are over a thousand of these, representing a significant percentage of the database.

In addition, we have added pages to list a highly-filtered set of a few dozen PRs that we think are ready-to-go, and another set of PRs that are the most-commonly-seen set.

Further, by request, we have added some scripts on freefall to allow a committer to pick a random PR to look at.

(I consider all of this work to be effective prototypes of pages that we would need to customize for any PR system. I have seen nothing yet that supports exactly what FreeBSD needs, out-of-the-box.)

(fwiw, most of this has been by suggestion, from either our new bugbusters, or src committers.)

Finally, many of the “I do not know how to make xyz work” PRs have been either closed, or are being handled by the new volunteers.

I have advertised all of this work on the wiki (including the relevant hrefs) on http://wiki.freebsd.org/BugBusting/Resources, and by announcements on the freebsd-bugbusters IRC and mailing lists, as well as selected cross-posting to other mailing lists.

So, what’s the problem?

Well …

This has resulted in only a handful of src commits.

Apparently I haven’t figured out how to get the src committers sufficiently interested to investigate these pages. I have gotten very little emailed feedback, and few committers showed up for the last bugathon.

So, the challenge is to keep our bugbusters interested in doing the triage work. IMHO, to keep the momentum that has been built up, we need to start getting some commits in.

Unfortunately, I do not seem to have the right ideas in place to make that happen. This is very frustrating.

I would be interested in getting suggestions on where to go from here. I am clearly missing something.