Linux glitches

[WebPilot]

Yep ... typo ... 60 GB.

With this configuration, I read where I can upgrade (reinstall) my system without 'mucking up' my HOME directory. We'll see.

[tufty]

Yep ... typo ... 60 GB.

With this configuration, I read where I can upgrade (reinstall) my system without 'mucking up' my HOME directory. We'll see.

Yep, hence my suggestion of putting /usr/local on a separate filesystem as well - any locally installed software should, by default, be installed to /usr/local, so you can blow away / without damaging anything you've installed manually. Modulo the problem with Linux putting all configuration files in /etc, and not using /usr/local/etc where relevant, but that's another issue (and one that's largely solved by using *BSD, except for a few braindead packages written by twats who've only ever used Linux and think it does everything the "right" way).

This approach doesn't always work if you're recovering a system to a newer version, particularly in cases where low-level libraries have changed (the glibc1-glibc2 change bit me hard there), but it does mean that, even if you manage to get / into a state where it's unusable / unbootable, all you have to use to get back up and running is the system install media, as opposed the then having to refind, rebuild and reinstall all the other cack you've built over time, plus all their dependencies.

It's a potentially valuable pain reduction exercise.

Simon

[WebPilot]

I wish to practice on this system in preparation for the inevitable day when I have to seriously upgrade my main system.

Thanks for the input.

[tufty]

I wish to practice on this system in preparation for the inevitable day when I have to seriously upgrade my main system.

Thanks for the input.

Sounds fair. Disaster recovery is always a good thing to practice. If you want to "simulate" a complete fuckup, `sudo rm -rf /etc` and then reboot. Whoopsie! Time for a reinstall!

Another thing you might want to consider is backups - if you have an external drive or NAS (or even a big, empty partition), you can do something very similar to Apple's "Time Machine" (apart from the bootable aspect and the system level detection of filesystem changes, which latter reduces the overhead of the backup process) using this : http://blog.interlinked.org/tutorials/r ... chine.html

Time Machine has been a life saver to me. Apart from the "oh, bugger, I really didn't mean to delete that" cases we all have, I had the hard drive go west on my iMac a couple of months back; from realising I had a dead drive to having a machine up and running exactly as it was prior to the disaster, including time taken to drive to the computer store and buy a new drive (an hour), disassemble and reassemble the iMac (no mean feat in itself, an hour and a half) and do the restore, was well under 4 hours.

[WebPilot]

 
 On my fresh Ubuntu 8.04 installation on my laptop, I tried to compile a simple 'Hello World' program. However, it throws up an error at

 #include <stdio.h>

and a search indicates that there is, indeed, no stdio.h nor for that matter, any header files.

The fix is to install libc6-dev.

[WebPilot]

 Under Ubuntu, after wine has been installed, it has been found that a µSoft windows executable can be run in a Terminal session a couple of ways. By typing

• wine and the program name (e.g. wine ./prog_name.exe)
• the program name (e.g. ./prog_name.exe)

 The 2nd method only works if permissions of the file is set to

   Execute: Allow executing file as program

  However, I believe this to be a default setting for this type of file.

[WebPilot]

 Ubuntu (as other flavors of Linux) is capable of reading and writing files stored on Windows formatted partitions. These partitions are normally formatted with NTFS, but are sometimes formatted with FAT32. You will also see FAT16 on other devices.

• Windows Vista, XP, 2000, older NT systems, and Windows Server 2003 and 2008 are formatted with NTFS.
• Older versions of Windows like Windows ME, 98, and 95 are formatted with FAT32.
• Flash drives, like your USB thumb drive or your camera's flash card are typically formatted as FAT16.

 In Windows, you can check what your partition is formatted as by right-clicking the partition in Windows Explorer and selecting Properties. In Ubuntu, run from terminal:

Code: Select all

sudo fdisk -l

[tufty]

However, I believe this to be a default setting for this type of file.

Christ almighty, I hope not.

The default permissions, or "setting", for any file or directory under a POSIX compliant system is defined by the umask of the user creating it, and the default flag settings for file creation for the application creating the file or directory.

Permissions are set for "owning" user, users in the same group, and "others", with the possibility of read access, write access, and execute access. These are not exclusive, so it is quite possible to have a directory that is write-only for anyone other than the owning user, allowing anyone to drop files into it, but no-one to see what's in there.

Typically, the permissions are described by a group of 3 octal numbers, denoting the binary r /w /x flags per user type. read/write/execute access is 7, read / write only is 6, and so on - no access at all is 0.

Generally, applications creating files attempt to create them with permissions of '666' (read/write for everyone), for *all* file types. there are a couple of notable exceptions, mainly compilers, but the vast majority of POSIX tools assume '666'. This is part of the reason why POSIX systems are generally difficult to infect with viruses, as no file is by default executable. Indeed, anything trying to create standard files with the execute bit set, without requiring intervention from the user, is a massive security hole. You'll see why in the next paragraph. Directories are created with permissions of '777' (read/write/execute for all, execute is read as "traverse" for directories).

The default settings used by the application are then combined, using a binary 'AND' operation, with the complement of the user's 'umask' setting. Typically, this is set to '022'. The complement of 022 is 755, which will result in a default permission of (assuming the above) '622' (read/write for owner, read only for everyone else, no execute anywhere) for "normal" files, and '755' for directories (read/write/traverse for owner, read/traverse for others). The 'standard' setting of 022 will *not* remove the execute bit from files being created by applications that can be considered as 'less than security conscious' (you'd need 133 for that).

There's more to it than this, but that's the basics.

Now, given the "standard" umask of 022 won't get rid of execute bits, if you're seeing .exe files being created with the execute bit set, there's a second massive security hole in your system beyond the ability to run windows apps without being asked about it.

[WebPilot]

... if you're seeing .exe files being created with the execute bit set, there's a second massive security hole in your system beyond the ability to run windows apps without being asked about it.

 You say but still have not explained to me why you consider these behaviors to be "massive security holes". What exactly are you afraid someone might do? Be specific - give me an example (or two or three).

[tufty]

... if you're seeing .exe files being created with the execute bit set, there's a second massive security hole in your system beyond the ability to run windows apps without being asked about it.

 You say but still have not explained to me why you consider these behaviors to be "massive security holes". What exactly are you afraid someone might do? Be specific - give me an example (or two or three).

Okay, consider the ILOVEYOU worm from 2000. It relied on people clicking an executable file in an email, and spread massively. The estimated cost of just getting rid of it was in the billions of dollars, not counting the cost of the outages it caused.

So, let's assume I want to make an ILOVEUBUNTU worm. I write an piece of malware, nastyprog, that relies on stuff I know exists in Ubuntu (the usual libc, libm and so on, in all the usual places). I mail it to you, with a message along the lines of "click on nastyprog if you want to see what Ubuntu can *really* do". Don't laugh, users haven't got any smarter since 2000, believe me.

So you double-click it. and your system (hopefully) says something along the lines of "* off, that doesn't have its executable bit set". Nothing happens. You're required to manually set the executable bit (chmod +x nastyprog) before you can run it. Requiring that single additional step is pretty much enough to save clueless users from themselves.

"Bugger", say I. So, I rewrite nastyprog to use the Win32 API, carefully restricting myself to stuff that Wine supports. Maybe I'm real clever and have additional code for Wine that also relies on having Linux stuff available, and the equivalent for Windows, allowing for non-wine-supported nastiness under Wine. The result is nastyprog.exe, a piece of malware supporting both Windows and Wine. So, I email that to you, same method as before, this time "ILOVEWINDOWSANDUBUNTU". If, as you are suggesting, the default perms for .exe files are 755, that file is executable - when you, the clueless user, click on it, it's passed to the kernel for execution. The kernel, with Wine hooked in at a low level, says "hey, this is a Windows executable, best we pass it off to wine", wine runs the app, and you're well and truly pwnt.

This is a very unsubtle approach, there's a load of other ways of sneaking executables onto people without them realising, but assuming .exe (or pe/coff files, depending on how the detection is done) are automagically considered executable, it's liable to succeed.

So. Why is automatically deciding what should be executable a bad idea?

Consider the context in which an untrusted executable runs. It's effectively running as *you* - it can do anything you can do. Now, if you're smart, you're not running as root, so it doesn't have total system destruction capability immediately. However, as the application is now effectively a local user, all it needs is a privileges escalation hole to get root (or, on most "consumer" *n*xes, to be able to trick you into entering your password for a 'sudo'). Kernel level privs escalation is not uncommon, although they get patched quite quickly once they're found, but you also need to consider all the software that's installed with a "default" ubuntu install. That's a massive attack surface, and you've already done the "difficult" part of getting access to the machine.

[WebPilot]

 
 I've made some progress to alter wine's behavior on my system. I'll post more as the day progresses.

[WebPilot]

 
 So, I desire to change wine's default behavior on my system. To this end, here is the beginning of what I've done so far.

 First, I installed ClamAV with the ClamTk GUI. I did this using Synaptic. Search for clamtk and clamav.

 I ran the program, ClamTk, choosing a Full Home scan. It took hours, but it eventually finished and found 3 viruses:

1. a pdf file with Exploit.PDF-34
2. the file, gendel32.exe, with VirTool.Gendel.A
3. an object file complaining Broken.Executeable

 Actually, I think this is not bad since I've been running Hardy Heron for the last 11 months with no protection at all.

[WebPilot]

 Some Experimentation:

 I went back to the directory where I have one of the executables from a .c code I wrote. I copied the file and renamed it to "copy".

 I double clicked "copy" from within Nautilus and the program, ClamAV, was launched by default checking the file for viruses - cool.

 From a terminal if I perform the following command,

$ file ./copy

 I receive the following response,

./copy: MS-DOS executable PE for MS Windows (console) Intel 80386 32-bit

 If the execution bit of the file, copy, is set and I type

$ ./copy

 the program will run using Wine; unset it won't.

[WebPilot]

I have found three things out now:

1. With no file extension, ClamAV is launched when the file is double clicked. Does it know the file is an "MS-DOS executable PE for MS Windows"? probably not.

2. With no file extension, Wine is not associated and does not know the file is a PE executable. Wine seems to be only associated with files whose names are suffixed with .exe.

3. An "MS-DOS executable PE for MS Windows", suffixed .exe or not, will run in a term as ./filename if the execution bit is set.

[tufty]

3. An "MS-DOS executable PE for MS Windows", suffixed .exe or not, will run in a term as ./filename if the execution bit is set.

That's the bit that worries me (or, more correctly, *would* worry me). It appears to me that somehow, Wine has got a hook into the execve() system call. I've found absolutely no documentation of this, either on the Wine site, the Ubuntu site, or elsewhere, apart from a few references I found to the to the "unified kernel" or whatever it's called.