Biker|Geek

I had fried turtles for supper!!!

UbuntuGuide.org has been updated for the latest version of Ubuntu. This is a huge guide that has tons of information on how to do just about anything in Ubuntu, including dealing with Windows partitions, networking, installing alternative desktop environments, and getting uncooperative graphics cards and wireless cards to work correctly. http://ubuntuguide.org/wiki/Ubuntu:Feisty

read more | digg story

Feisty Fawn brings a number of notable enhancements to the Linux desktop including a new Windows desktop migration tool. When installing Ubuntu next to Windows in a dual boot, the migration tool can detect that and import bookmarks, files and more, making it easier to migrate from Windows.

The latest version of Ubuntu also features easy-to-install multimedia codecs. To get around legal restrictions in various countries the Feisty team has implemented some guided install wizards for those wanting to add codecs.

The other noteworthy feature of the new release is a revamped wireless tool by the name of Avahi. When joining a wireless network, Avahi automatically discovers publicly available machines on that network making it easy to access printers, music and more.

The servers have been heavily burdened for most of the weekend and I just now was able to get the torrent file for the Kubuntu 7.04 DVD. I have been running the beta for a few weeks now with only a couple of minor issues, probably due to some specific hardware I’m using.

Here’s the links to the download severs:

Ubuntu: http://ubuntu-releases.optus.net/feisty/

Kubuntu: http://www.kubuntu.org/download.php

I just watched the first two movies again and I must say I can’t wait to see this movie. Even my kids are excited to see it. Check it out.

I found this at: http://www.packetstormsecurity.org/filedesc/truecrypt-dos.txt.html

It seems to be possible to perform various denial of service attacks on a Linux computer running TrueCrypt version 4.3 in setuid root mode, or possibly introduce evil binaries into normally trusted locations.

Here’s a repost of the text file at: http://www.packetstormsecurity.org/0703-advisories/truecrypt-dos.txt

TrueCrypt 4.3 for Linux from http://www.truecrypt.org/

It seems to be possible to perform various denial of service attacks on a Linux
computer running TrueCrypt in set-uid root mode, or possible introduce evil
binaries into normally trusted locations. I tested this on the latest
version, 4.3, which corrected another vulnerability, but it still seems
insecure.

The following command mounts a file-based container over /usr/bin. This can be
done by a non-root user provided TrueCrypt is in set-uid mode, and the file
container does not have to contain any files:

tim# truecrypt -u myvolume.tc /usr/bin

This could result in system binaries becoming inaccessible, or if the user
has copied his own binaries into the file container, they could potentially
replace legitimate system binaries with malicious ones, e.g. a /usr/bin/sudo
that does something nasty.

To do this I did the following (as non-root).

# truecrypt -c # create a FAT32 volume called test.tc
# truecrypt -u test.tc tmpdir # mount in a tmp dir in my home dir
# cd tmpdir
# cp ../badbinary ./sudo # copy in an evil binary from somewhere
# chmod +x sudo
# truecrypt -d # unmount the volume
# truecrypt -u test.tc /usr/bin # mount same volume over /usr/bin

All other system binaries (e.g. screen etc.) are now inaccessible, but if a
user (or root) runs sudo (or whatever the user names it) in the meantime before
someone realises something is wrong, the malicious binary will be executed.

Because the umount and truecrypt binaries reside in /usr/bin, if they have
been “masked” by an empty container mounted on /usr/bin, it may not be possible
to recover the system without a reboot.

It also seems possible to arbitrarily deny users local (and possibly remote)
access to the system, for example through the following command:

tim# truecrypt -u myvolume.tc /home/sally

Even if the user does not have write access to /home/sally, the unrestricted
set-uid operation means that “tim” has now “mounted over” sally’s home
directory. If sally is currently logged in, her files will appear to
“disappear” because they have been mounted over. If user sally tries to log
in, in my tests she cannot then log in graphically because some of her
configuration files have become inaccessible. User sally has been denied
access to the system by a non-root user.

I believe there also may be another vulnerability here. If user sally could
log in (e.g. through a terminal), any files she writes to “/home/sally” will
actually be re-directed to the volume mounted by user tim. If the file-hosted
volume is FAT32, user tim could potentially “steal” files as they are written
not to sally’s regular home directory but to the FAT32 volume. I have been
unable to test this successfully though since it seems user sally cannot log in
after this denial of service is performed.

There seems to be other ways to perform a DoS too. Mounting a volume (even if
empty) over /tmp affects operation of the system (users cannot log in through
X), and mounting over /var/log could be done to subvert system log messages to
a FAT32 volume that can be read by any user.

A “workaround” is to remove the set-uid bit from /usr/bin/truecrypt, but then
only root can mount TrueCrypt volumes. It seems there needs to be much
tigher control on where non-root users can mount their volumes to.

– Tim Rees