Monday, December 21, 2009
Ubuntu movie sighting
I was watching the Millenium movie last night, and spotted an Ubuntu desktop being used by the "Plague" character:
Wednesday, November 4, 2009
GNOME Keyring
For the past week or so, people have been talking about a “security issue” in Seahorse. This sums up my opinion on the matter:
This isn't a security issue, and there is no good way to fix it.
There, I've said it. Now, here's some background:
Although people are talking about Seahorse, the actual application that manages passwords is called GNOME Keyring. GNOME Keyring is an application that manages a user's authentication information, such as user names and passwords. It stores the authentication information in one or more encrypted databases, called keyrings. A password, supplied by the user, is required to unlock a keyring, at which point all the information contained within is decrypted and is made available to applications via the libgnome-keyring library. It is similar to the Keychain in Mac OS X, and Protected Storage in Microsoft Windows.
Traditionally, a desktop application that needed to remember a user's password, such as an email or an instant messaging program, would store the password in a hidden config file in the user's home directory. Appropriate permissions would be set on the file to make sure other local users can't read it.
Sometimes, passwords stored in this manner would be obfuscated using a reversible scheme, as the password needs to be converted back to plain text in order to be used. This would provide a false sense of security. Users inspecting the file would think the passwords were encrypted, but a myriad of little recovery scripts and on-line converters were available to anyone who knows how to perform a Google search.
A password managing daemon, such as GNOME Keyring, increases the security of stored passwords for the following reasons:
So, if GNOME Keyring increases the security of user credentials, why can you see your passwords exposed in plain text when you open Seahorse? Because you've unlocked the keyring using your login password.
Although GNOME Keyring supports multiple keyrings, there is only one by default, called “login”. This keyring is automatically unlocked by a PAM module when logging into a GNOME desktop. When the desktop session is closed, the keyring is locked. When the keyring is in an “unlocked” state, the database files are decrypted using the decryption password and all the contents are in memory for gnome-keyring-daemon to access.
Now, the attack scenario that has been talked about this past week has been leaving your computer unattended, and an attacker using Seahorse to access your clear text passwords. This has been criticized as being a security issue, and a few “solutions” have been suggested to “fix” the issue. Here are some of the scenarios proposed:
Scenario 1: Ask for the user's password before displaying the clear text keyring contents.
This scenario doesn't work in practice. Once the keyring is unlocked, the contents are available under the user's security context. Since the GNOME Keyring daemon is under the user's security context, the intruder has every privilege necessary to simply bypass the authentication step and directly read the unencrypted keyring from memory. Even if Seahorse asked for a user password, nothing could prevent the intruder from simply downloading a “reveal passwords” application from the Internet or a USB key. There is no difference in time or skill required to open Seahorse and display passwords, or to type “gnome password revealer” in Google and execute the first application available for download. The GNOME Keyring project has a web page to explain this.
Even worse, the fact that a password would be required in Seahorse would make the user think that a password is required to see the clear text information. This would give the user a false sense of security. If Seahorse asks for a password, but a five line python script can bypass the password, bug reports would change from “Seahorse displays clear text passwords” to “Seahorse authentication can be easily bypassed”. This scenario doesn't solve the problem.
Scenario 2: Make keyring session expire automatically after a certain time.
If the keyring session expires automatically, such as every 15 minutes, it becomes useless. The purpose of the keyring is to store passwords that are needed by applications. With keyring session expiration, Evolution can't automatically check for new mail, Empathy can't auto-reconnect to instant messaging networks, the wireless connection can't re-authenticate to access points.
If you expire the keyring session every 15 minutes, you will probably need to type in your password every 15 minutes. Besides, if you leave your computer unattended, 15 minutes is long enough for an intruder to steal your passwords. This scenario doesn't solve the problem.
Scenario 3: Make the keyring daemon run as root or as a dedicated user.
The idea behind this is to have a central daemon that would authenticate users and applications before giving out passwords. Since the daemon doesn't run under the user's security context, no amount of hacking by an intruder in an unlocked desktop session would result in gaining access to the unlocked password database.
Although this scenario may seem appealing, it would probably be less secure than the current approach. If we have a central daemon that serves all users, a programming vulnerability could result in other users gaining access to your confidential information. Besides, if your desktop applications, under your security context, can gain access to the passwords they need, so can an intruder in your security context. The intruder's script can simply spoof the desktop applications themselves to get the passwords, or get them out of the application's memory. This scenario doesn't solve the problem.
Scenario 4: Stop using GNOME Keyring.
Well, GNOME Keyring was created to solve the problem of people writing down their passwords everywhere, including text files or their computer, and the problem of applications storing passwords in text files. Removing GNOME Keyring would decrease security to the state it was before. This scenario doesn't solve the problem.
Scenario 5: Locking the desktop session when stepping away from the keyboard.
Now we're getting somewhere!
Since the attack vector that's being discussed is an intruder gaining physical access to an unlocked desktop, the simplest way to prevent this from happening is to lock the desktop when you leave it unattended.
If someone gains access to your desktop, your passwords are not the only thing they can access. Who needs your email password, when they have access to your whole mail file?
Even if we assume GNOME Keyring could be made attacker proof, we would need to do the same for every desktop application. An intruder could, in a few seconds, install a Trojan horse downloaded off the Internet that runs in the background and emails him your passwords as soon as your desktop applications use them. The same application could intercept your sudo password, and become root to access the GNOME Keyring data. Absolutely no technical skill is required to do this.
Leaving your desktop unattended exposes all your confidential data to an attacker, not just your passwords.
Game Over.
Recommendations:
And remember: This isn't a security issue, and there is no good way to fix it.
This isn't a security issue, and there is no good way to fix it.
There, I've said it. Now, here's some background:
Although people are talking about Seahorse, the actual application that manages passwords is called GNOME Keyring. GNOME Keyring is an application that manages a user's authentication information, such as user names and passwords. It stores the authentication information in one or more encrypted databases, called keyrings. A password, supplied by the user, is required to unlock a keyring, at which point all the information contained within is decrypted and is made available to applications via the libgnome-keyring library. It is similar to the Keychain in Mac OS X, and Protected Storage in Microsoft Windows.
Traditionally, a desktop application that needed to remember a user's password, such as an email or an instant messaging program, would store the password in a hidden config file in the user's home directory. Appropriate permissions would be set on the file to make sure other local users can't read it.
Sometimes, passwords stored in this manner would be obfuscated using a reversible scheme, as the password needs to be converted back to plain text in order to be used. This would provide a false sense of security. Users inspecting the file would think the passwords were encrypted, but a myriad of little recovery scripts and on-line converters were available to anyone who knows how to perform a Google search.
A password managing daemon, such as GNOME Keyring, increases the security of stored passwords for the following reasons:
- Passwords are stored in a database that uses real encryption, not just an obfuscation scheme
- A single code base needs to be audited to make sure no vulnerabilities exist in the encryption algorithms that are being used
- The database is protected by a password that is known only to the user who unlocks it
- Since the database is encrypted, no other user or bootable CD can recover the stored passwords if the unlock password is not known
So, if GNOME Keyring increases the security of user credentials, why can you see your passwords exposed in plain text when you open Seahorse? Because you've unlocked the keyring using your login password.
Although GNOME Keyring supports multiple keyrings, there is only one by default, called “login”. This keyring is automatically unlocked by a PAM module when logging into a GNOME desktop. When the desktop session is closed, the keyring is locked. When the keyring is in an “unlocked” state, the database files are decrypted using the decryption password and all the contents are in memory for gnome-keyring-daemon to access.
Now, the attack scenario that has been talked about this past week has been leaving your computer unattended, and an attacker using Seahorse to access your clear text passwords. This has been criticized as being a security issue, and a few “solutions” have been suggested to “fix” the issue. Here are some of the scenarios proposed:
Scenario 1: Ask for the user's password before displaying the clear text keyring contents.
This scenario doesn't work in practice. Once the keyring is unlocked, the contents are available under the user's security context. Since the GNOME Keyring daemon is under the user's security context, the intruder has every privilege necessary to simply bypass the authentication step and directly read the unencrypted keyring from memory. Even if Seahorse asked for a user password, nothing could prevent the intruder from simply downloading a “reveal passwords” application from the Internet or a USB key. There is no difference in time or skill required to open Seahorse and display passwords, or to type “gnome password revealer” in Google and execute the first application available for download. The GNOME Keyring project has a web page to explain this.
Even worse, the fact that a password would be required in Seahorse would make the user think that a password is required to see the clear text information. This would give the user a false sense of security. If Seahorse asks for a password, but a five line python script can bypass the password, bug reports would change from “Seahorse displays clear text passwords” to “Seahorse authentication can be easily bypassed”. This scenario doesn't solve the problem.
Scenario 2: Make keyring session expire automatically after a certain time.
If the keyring session expires automatically, such as every 15 minutes, it becomes useless. The purpose of the keyring is to store passwords that are needed by applications. With keyring session expiration, Evolution can't automatically check for new mail, Empathy can't auto-reconnect to instant messaging networks, the wireless connection can't re-authenticate to access points.
If you expire the keyring session every 15 minutes, you will probably need to type in your password every 15 minutes. Besides, if you leave your computer unattended, 15 minutes is long enough for an intruder to steal your passwords. This scenario doesn't solve the problem.
Scenario 3: Make the keyring daemon run as root or as a dedicated user.
The idea behind this is to have a central daemon that would authenticate users and applications before giving out passwords. Since the daemon doesn't run under the user's security context, no amount of hacking by an intruder in an unlocked desktop session would result in gaining access to the unlocked password database.
Although this scenario may seem appealing, it would probably be less secure than the current approach. If we have a central daemon that serves all users, a programming vulnerability could result in other users gaining access to your confidential information. Besides, if your desktop applications, under your security context, can gain access to the passwords they need, so can an intruder in your security context. The intruder's script can simply spoof the desktop applications themselves to get the passwords, or get them out of the application's memory. This scenario doesn't solve the problem.
Scenario 4: Stop using GNOME Keyring.
Well, GNOME Keyring was created to solve the problem of people writing down their passwords everywhere, including text files or their computer, and the problem of applications storing passwords in text files. Removing GNOME Keyring would decrease security to the state it was before. This scenario doesn't solve the problem.
Scenario 5: Locking the desktop session when stepping away from the keyboard.
Now we're getting somewhere!
Since the attack vector that's being discussed is an intruder gaining physical access to an unlocked desktop, the simplest way to prevent this from happening is to lock the desktop when you leave it unattended.
If someone gains access to your desktop, your passwords are not the only thing they can access. Who needs your email password, when they have access to your whole mail file?
Even if we assume GNOME Keyring could be made attacker proof, we would need to do the same for every desktop application. An intruder could, in a few seconds, install a Trojan horse downloaded off the Internet that runs in the background and emails him your passwords as soon as your desktop applications use them. The same application could intercept your sudo password, and become root to access the GNOME Keyring data. Absolutely no technical skill is required to do this.
Leaving your desktop unattended exposes all your confidential data to an attacker, not just your passwords.
Game Over.
Recommendations:
- Always lock your screen when you leave your computer unattended. This is akin to locking your front door when leaving the house. Hit Ctrl-Alt-L, select “Lock Screen” from the user switch applet, or put the “Lock Screen” applet somewhere in your panel for easy access.
- Set a low screen-saver idle timeout, for example, 5 minutes. If you forget to lock your session, it will do so automatically after a couple of minutes, reducing the time your confidential data is exposed.
And remember: This isn't a security issue, and there is no good way to fix it.
Sunday, August 30, 2009
The ideal portable media player
After the overwhelming response to my Goodbye Apple blog post, I have compiled a list of criteria I would like to see in a portable music player:
Linux compatibility
This is a deal-breaker for me, as I only use Ubuntu. The next mp3 player should be manageable from a Ubuntu desktop. In order of preference:
Of course, I would also need to be able to update the device's firmware, but this isn't a must. I can probably find someone with a Windows box to do a one-time firmware update.
Video support
I spend a lot of time in airports and planes. This is where I use my player the most. I like watching videos and movies while on the move. I want at least a 2.5 inch screen, but it still needs to be light and small enough to fit in my shirt pocket. It's what I had on my 5G iPod Video, and it's the minimum I would tolerate.
Video conversion should be easy, and should not require Windows-only software. I should be able to encode video from DVDs I own, and from video podcasts I download from the Internet.
Bonus points if the manufacturer gives some example ffmpeg or mencoder command-lines in a wiki somewhere, or submits presets for their device to encoding software such as Handbrake.
Podcast support
I listen to a lot of podcasts. Since a lot of podcasts are available encoded in mp3 format, most people think they work on any mp3 player. Fact is, I want the player to be able to recognize podcasts and apply special logic to them the way iPods do. They need to:
The most important criteria for me is the automatic resume one, and is the one most media players are lacking. I don't enjoy losing my place in a podcast when I get interrupted, or want to listen to some music. Trying to locate where you were in an hour-long podcast with a fast-forward button is painful.
Standard USB port
I want a media player with a standard mini or micro USB port for syncing and charging. I hate having to spend extra on spare proprietary cables. I hate having to lug ten different proprietary cables in my laptop bag when I travel. And most of all: I hate forgetting the proprietary cable at home when I leave on a trip. Even though the iPod has a proprietary connector, at least you can purchase a spare cable pretty much anywhere.
Of course, most devices come with proprietary ports because a standard USB port can't offer all the extra features that a portable media device needs, such as TV Out, Audio Out, Line in, etc. How about this for an idea, folks: USB for syncing/charging, and proprietary port for all the rest.
User-friendly interface
My dad came over the other day with a cheap no-name 3rd generation iPod Nano knockoff he bought at an electronics store. He was raving about how inexpensive it was.
The user interface was the most horrible thing I have ever encountered. It was so complicated to simply get a song to play that I would have paid double the price difference to never see it again.
On-demand playlist support
Although this isn't something that's absolutely necessary, I really enjoy listening to music while creating a playlist on the device itself.
Adequate volume
The volume needs to be loud enough to listen to music and movies while on a plane. My Sony PSP isn't loud enough for me to listen to movies on a plane.
Open multimedia format support
It would be great if the device supported open multimedia formats and codecs, such as Ogg, FLAC and Theora.
Well, that's all I can think of for now. Based on recommendations in my blog comments, I have purchased a Cowon S9. Also, I have received a Creative Zen MX, and will be receiving a Sansa Fuse shortly. In the coming weeks, I'll be reviewing each of these (and maybe others) to try and find the ideal portable media player for Linux users.
Linux compatibility
This is a deal-breaker for me, as I only use Ubuntu. The next mp3 player should be manageable from a Ubuntu desktop. In order of preference:
- Manufacturer lists Linux support or compatibility on the box
- Manufacturer lists Linux support or compatibility on their website
- Device is known to work with Linux
Of course, I would also need to be able to update the device's firmware, but this isn't a must. I can probably find someone with a Windows box to do a one-time firmware update.
Video support
I spend a lot of time in airports and planes. This is where I use my player the most. I like watching videos and movies while on the move. I want at least a 2.5 inch screen, but it still needs to be light and small enough to fit in my shirt pocket. It's what I had on my 5G iPod Video, and it's the minimum I would tolerate.
Video conversion should be easy, and should not require Windows-only software. I should be able to encode video from DVDs I own, and from video podcasts I download from the Internet.
Bonus points if the manufacturer gives some example ffmpeg or mencoder command-lines in a wiki somewhere, or submits presets for their device to encoding software such as Handbrake.
Podcast support
I listen to a lot of podcasts. Since a lot of podcasts are available encoded in mp3 format, most people think they work on any mp3 player. Fact is, I want the player to be able to recognize podcasts and apply special logic to them the way iPods do. They need to:
- Have a “completed” flag to be able to easily spot the ones I've listened to already
- Automatically resume from where they were left off (without having to manually set a “bookmark”)
- Be in a separate list from regular music files
The most important criteria for me is the automatic resume one, and is the one most media players are lacking. I don't enjoy losing my place in a podcast when I get interrupted, or want to listen to some music. Trying to locate where you were in an hour-long podcast with a fast-forward button is painful.
Standard USB port
I want a media player with a standard mini or micro USB port for syncing and charging. I hate having to spend extra on spare proprietary cables. I hate having to lug ten different proprietary cables in my laptop bag when I travel. And most of all: I hate forgetting the proprietary cable at home when I leave on a trip. Even though the iPod has a proprietary connector, at least you can purchase a spare cable pretty much anywhere.
Of course, most devices come with proprietary ports because a standard USB port can't offer all the extra features that a portable media device needs, such as TV Out, Audio Out, Line in, etc. How about this for an idea, folks: USB for syncing/charging, and proprietary port for all the rest.
User-friendly interface
My dad came over the other day with a cheap no-name 3rd generation iPod Nano knockoff he bought at an electronics store. He was raving about how inexpensive it was.
The user interface was the most horrible thing I have ever encountered. It was so complicated to simply get a song to play that I would have paid double the price difference to never see it again.
On-demand playlist support
Although this isn't something that's absolutely necessary, I really enjoy listening to music while creating a playlist on the device itself.
Adequate volume
The volume needs to be loud enough to listen to music and movies while on a plane. My Sony PSP isn't loud enough for me to listen to movies on a plane.
Open multimedia format support
It would be great if the device supported open multimedia formats and codecs, such as Ogg, FLAC and Theora.
Well, that's all I can think of for now. Based on recommendations in my blog comments, I have purchased a Cowon S9. Also, I have received a Creative Zen MX, and will be receiving a Sansa Fuse shortly. In the coming weeks, I'll be reviewing each of these (and maybe others) to try and find the ideal portable media player for Linux users.
Tuesday, August 18, 2009
My God! It's full of stars!
Ever try hooking up a server or firewall with multiple network cards? You stand in back of it wondering which RJ45 port is eth0, which one is eth1...
Here's a little tip: you can make network card lights blink with the ethtool command:
You can make each card blink for 30 seconds in order with something like:
Here's a little tip: you can make network card lights blink with the ethtool command:
ethtool -p eth0
You can make each card blink for 30 seconds in order with something like:
for net in eth0 eth1 eth2; do ethtool -p $net 30; done
Saturday, August 15, 2009
Aide (Advanced Intrusion Detection Environment) improvements
At the Karmic Ubuntu developer summit, we had a session on filesystem integrity checkers. The main purpose of the session was to see what the current state of them was, and if we needed to replace Aide in main with a newer alternative.
I don't traditionally like filesystem checkers. While they are very useful to detect files that get modified during an intrusion, an administrator needs to invest an incredible amount of time in analyzing the log files that they produce every day. This is compounded by the fact that servers don't remain static: they get security and stability software updates installed. The more that servers get updated, the more they divert from the original database that was generated by the integrity checker, and the more false positives get reported in the log.
Wouldn't it be great if the integrity checker was smart enough not to report on files that were changed by operating system updates?
I introduced this very feature in the Aide package in Karmic Koala. It is disabled by default. To activate it, simply modify the /etc/default/aide configuration file and set “FILTERUPDATES” to “yes”. I also recommend changing “COPYNEWDB” to “yes” in order to get changes reported only once.
This new configuration option will filter out files that were modified by operating system updates from the daily email sent to the administrator. It will not filter them out from the main log file.
Of course, overwriting the pristine database every day and filtering out the files changed by system updates may slightly reduce Aide's effectiveness, but I think it's a compromise worth having if the alternative is to not use Aide at all because of administrative overhead.
If you've never used Aide before on your Ubuntu server, and would like to give it a try on Karmic, here are the steps necessary to get started:
1- Install aide:
2- Create the initial database (this may take a while):
3- Customize the MAILTO, COPYNEWDB and FILTERUPDATES parameters in /etc/default/aide
4- You should now get a daily email report on filesystem changes!
I don't traditionally like filesystem checkers. While they are very useful to detect files that get modified during an intrusion, an administrator needs to invest an incredible amount of time in analyzing the log files that they produce every day. This is compounded by the fact that servers don't remain static: they get security and stability software updates installed. The more that servers get updated, the more they divert from the original database that was generated by the integrity checker, and the more false positives get reported in the log.
Wouldn't it be great if the integrity checker was smart enough not to report on files that were changed by operating system updates?
I introduced this very feature in the Aide package in Karmic Koala. It is disabled by default. To activate it, simply modify the /etc/default/aide configuration file and set “FILTERUPDATES” to “yes”. I also recommend changing “COPYNEWDB” to “yes” in order to get changes reported only once.
This new configuration option will filter out files that were modified by operating system updates from the daily email sent to the administrator. It will not filter them out from the main log file.
Of course, overwriting the pristine database every day and filtering out the files changed by system updates may slightly reduce Aide's effectiveness, but I think it's a compromise worth having if the alternative is to not use Aide at all because of administrative overhead.
If you've never used Aide before on your Ubuntu server, and would like to give it a try on Karmic, here are the steps necessary to get started:
1- Install aide:
apt-get install aide
2- Create the initial database (this may take a while):
aideinit
3- Customize the MAILTO, COPYNEWDB and FILTERUPDATES parameters in /etc/default/aide
4- You should now get a daily email report on filesystem changes!
Thursday, July 23, 2009
Goodbye Apple
I've owned a lot of iPods. My wife has owned a lot of iPods.
Not anymore.
For the longest time, I could use gtkpod to seamlessly access my iPods from my Ubuntu desktop. It initially took some reverse-engineering effort to understand the iPod's data format to be able to access it from non-iTunes software, but it was possible. All of a sudden, Apple is trying everything they can to prohibit interopability.
First, they encrypted the firmware, blocking the use of third-party firmware like Rockbox and iPod Linux. This doesn't bother me much, as I always prefered the original Apple firmware anyway.
Then, in August 2007, they added a new hash to the database to block non-iTunes software. This was quicky reverse-engineered and support was added to gtkpod once again.
In November 2008, they changed the hash again. This time, Apple used code-obfuscation software on iTunes in an effort to complicate reverse-engineering a second time. When a wiki was put up to start documenting the new hash, Apple sent a takedown notice. Fortunately, some people found an ugly workaround to get gtkpod working again.
In 2009, Palm released the Palm Pre. It supported syncing with iTunes. Apple retaliated by updating iTunes specifically to block Palm Pre interopability. Unfortunately, this changed the iPod database structure, and the workaround for gtkpod no longer works.
While I can understand Apple not wanting the Palm Pre to be able to sync with iTunes, as iTunes integration is one of the main selling points for the iPod, I can't understand why they would actively block third party software from accessing the iPod.
Everyone is now selling DRM-free mp3 music, so it's not a question of protecting DRM. You'd think they would want to sell more iPods, not block a certain percentage of their market out.
My 5G iPod broke today. Dear Apple, the replacement I purchase won't be from you.
Not anymore.
For the longest time, I could use gtkpod to seamlessly access my iPods from my Ubuntu desktop. It initially took some reverse-engineering effort to understand the iPod's data format to be able to access it from non-iTunes software, but it was possible. All of a sudden, Apple is trying everything they can to prohibit interopability.
First, they encrypted the firmware, blocking the use of third-party firmware like Rockbox and iPod Linux. This doesn't bother me much, as I always prefered the original Apple firmware anyway.
Then, in August 2007, they added a new hash to the database to block non-iTunes software. This was quicky reverse-engineered and support was added to gtkpod once again.
In November 2008, they changed the hash again. This time, Apple used code-obfuscation software on iTunes in an effort to complicate reverse-engineering a second time. When a wiki was put up to start documenting the new hash, Apple sent a takedown notice. Fortunately, some people found an ugly workaround to get gtkpod working again.
In 2009, Palm released the Palm Pre. It supported syncing with iTunes. Apple retaliated by updating iTunes specifically to block Palm Pre interopability. Unfortunately, this changed the iPod database structure, and the workaround for gtkpod no longer works.
While I can understand Apple not wanting the Palm Pre to be able to sync with iTunes, as iTunes integration is one of the main selling points for the iPod, I can't understand why they would actively block third party software from accessing the iPod.
Everyone is now selling DRM-free mp3 music, so it's not a question of protecting DRM. You'd think they would want to sell more iPods, not block a certain percentage of their market out.
My 5G iPod broke today. Dear Apple, the replacement I purchase won't be from you.
Subscribe to:
Posts (Atom)