Subscribe to the RSS Feed


FreeBSD LD_PRELOAD security fault

This issue was disclosed yesterday sharing a local root exploit for FreeBSD systems. This blog post investigates and explains the issue, also the links and comments are worth reading. There are two types of exploits out there, one requires a setuid root binary to work, the other will use setuid(2).

An initial fix has been committed into the CVS today.

Posted 2009/12/01 23:01 by alex · Comment

PureFTPD virtual chroot

PureFTPD has a feature called “virtual chroot”, where it will mimic a chroot by its own means, but without using the chroot() system call.

An excerpt from the PureFTPD FAQ:

– The ‘virtual chroot’ implementation. With that feature, users can
follow all symbolic links, even when they don’t point inside the jail. This
is very handy to set up directories shared by multiple users. Binary
packages are compiled with virtual chroot by default.

To enable the virtual chroot feature when you are compiling the server, use
the —with-virtualchroot with ./configure . If you want a restricted chroot,
don’t include —with-virtualchroot.

Please note that the FTP server will never let people create new symbolic
links. Symbolic links have to be already there to be followed. Or if your
users can create symbolic links through Perl or PHP scripts, your hosting
platform is really badly configured. People can install any web file
browser, they don’t need FTP to look at your system files. Recompile PHP
without POSIX functions and run all Perl scripts chrooted.

This feature is turned on by default in the FreeBSD ports.

Jos sent in a comment to the ports maintainer of pureftpd noting the above problem and today they have made this selectable when compiling the package.

Freshports commit message and direct link to CVS.

Posted 2009/11/30 14:51 by alex · Comment

Grow FreeBSD UFS filesystem on VmWare HDDs

In this artice I’m going to show you how to expand your UFS filesystem under FreeBSD that runs in a Vmware Virtual Machine.

FreeBSD uses slices instead of traditional PC partitions. To sum it up shortly, it means that your whole disk contains only a single traditional partition with the partition type ‘freebsd(165)’. Inside this partition you will have slices. In a typical FreeBSD installation you have seperate slices for /, /usr, /var, /tmp and swap. In most cases the last slice on the partition is the /usr, and hopefully this is the one we have to extend, because in this case the only thing needed is to add some space to the end of the drive and extend the last slice. Sounds easy? Don’t think so!

The main steps are:

  1. Increase the actual (virtual) hdd size
  2. Extend the partition to cover the whole disk
  3. Extend the size of the last slice to cover the whole partition
  4. Extend the actual UFS filesystem on the newly modified slice

All the details:
First, forget livecds like gparted-live, knoppix, other partition hacking tools because they will not work.

Posted 2009/11/30 07:31 by jos · Comment [3]

VIMAGE - Better virtualization in FreeBSD 8

Now that FreeBSD 8 is out, among many changes we can find enhancements in the field of virtualization as well. A newly developed virtualization container called VIMAGE has been implemented to enable virtualization of the FreeBSD network stack.

As you may know previous releases of FreeBSD had support only for jails with IP addresses of the main network stack; meaning once you configured IP/IPv6 addresses on your host system, a subset of those addresses could be associated to each one of your jails. As simple as it sounds, it actually doesn’t let you perform several networking related tasks inside of a jail, and you couldn’t separate your jails from each other with a firewall as there were no real interfaces present in your system.

With VIMAGE you have a jail with full instance of the host’s networking stack, including loopback interface, routing tables, etc. Network interfaces created on the host system can be moved to any VIMAGE jail to enable its connection to the outside world with a new option of ifconfig called “vnet”.

vnet jail
Move the interface to the jail , specified by name or JID. If the jail has a virtual network stack, the interface will disap- pear from the current environment and become visible to the jail.

Note: Option “-vnet” does the opposite.

As you might not have as many network interfaces as jails, you might need some workarounds to tunnel network traffic between two interfaces of your system.

Forget TUN/TAP and VPNs. FreeBSD 8 has a special network device called epair , which lets you create a pair of interconnected ethernet interfaces. If you move one of them to a VIMAGE jail you are basicly done. Feel free to bridge them or use VLANs, they will still work. I don’t know about the overhead of epair, but if all you care about is security, this might be the best choice for you on FreeBSD.

To enable VIMAGE you have to add “option VIMAGE” to your kernel configuration file and recompile/reinstall it.

Posted 2009/11/27 22:06 by jos · Comment [1]

getlogin vs getpwuid

getlogin (2):

The getlogin() routine returns the login name of the user associated with the current session, as previously set by setlogin(). The name is normally associated with a login shell at the time a session is created, and is inherited by all processes descended from the login shell. (This is true even if some of those processes assume another user ID, for example when su(1) is used).

getpwuid (3):

The functions getpwnam() and getpwuid() search the password database for the given login name or user uid, respectively, always returning the first one encountered.

One can get the current username using getpwuid with the following code:

struct passwd *tmp;
tmp = getpwuid(getuid());
printf(“username: %s\n”, tmp->pw_name)

Also note getpwuid_r (3) which is the thread safe version of the above.

Why is it better using getpwuid than getlogin? Imagine you are setting up a chrooted/jailed environment. getpwuid will always give back consistent results, while getlogin will tell different credentials if jexec/su/sudo is used.

Posted 2009/11/17 11:28 by alex · Comment

← Previously Recently →