Seeking New Admins for Fedora and GSoC

I have really enjoyed my role as an administrator for Fedora’s participation in Google’s Summer of Code. It has been a very rewarding experience and I have been both grateful for and proud of all of the mentors and students that have participated.

Karsten Wade has been extremely helpful as a fellow administrator and has really helped Fedora’s participation succeed. Last week, he wrote that he would like to pass the reigns. His work on Fedora’s own student programs is extremely important, and I am pleased to see that he is focusing on that work.

As much as I enjoy working as an administrator for Fedora’s GSoC participation, I also have too much on my plate to give the time and attention to the program that it really needs and deserves. Therefore, I too must step aside and allow others to take a turn at the wheel.

Both the administrator and mentor roles in the Summer of Code are wonderful opportunities. Karsten lists the benefits and caveats of the administrator role in his post, and I think he sums them up perfectly, so I will not repeat them. There are some important points I would like to add about being an administrator with Fedora for the Summer of Code:

  • All projects chiefly sponsored by Red Hat are required to participate together, so administrators can come from the communities of Fedora, JBoss.org or other Red Hat-sponsored projects and must be prepared to coordinate efforts across communities.
  • This is not a full-time job. If you can spare a few hours a week and respond in a timely manner to communications, you can handle the workload. There are a few deadlines to be met, and you might have to make an IRC meeting or two.
  • Karsten and I will both be “around” to help by answering questions and offering guidance. I do not have the time to handle all of the administrative duties, but I will be happy to help as much as I can.
  • One of the biggest challenges in the past has been recruitment – gathering administrators, mentors, ideas and students. In some ways, this has gotten easier, but know that this is an important part of the job.
  • Fedora’s participation in GSoC 2011 is not guaranteed. The new administrators will need to ready the prerequisites and prepare the application when the application window opens.

If you might like to serve as an administrator for Fedora’s participation in Google’s Summer of Code, please contact me right away.

So Long, and Thanks for All the Fish

The efforts of Fedora’s Summer Coding SIG and our umbrella “Red Hat Summer” effort got a small setback today. After 5 years of successful participation in the Google Summer of Code program, we were not accepted into this year’s Summer of Code. While this was unexpected and a little disappointing, it does not stop our summer coding work.

In 2008, Google required the Fedora Project and JBoss.org teams to apply as a single organization to the Summer of Code, since both are Red Hat-sponsored open source projects. While that created some hurdles for us, since we are two very distinct communities with almost no overlap, we met the challenge head-on and created our “Red Hat Summer” group to coordinate our efforts and bring the teams together for our common goal.

“Give a man a fish, and you have fed him for a day. Teach a man to fish, and you have fed him for a lifetime.”

As soon as Fedora and JBoss.org began working cooperatively, we also began to focus on making our efforts and resources more generic, such that we could take “Google Summer of Code” and replace “Google” and “Code” with any sponsor and any deliverable of interest. We began slowly working on an architecture that would allow us to support other seasonal development for students without a strict dependency on Google’s program.

We have greatly appreciated what Google has done with the Summer of Code program, and we are disappointed that we will not be participating this year. I have enjoyed my role as a mentor since 2005 and organization administrator since 2006, and my summer just won’t be the same, but we are going to take the opportunity to quickly advance our non-GSoC summer coding initiatives. We will still welcome students to work under our guidance this year, and we are hard at work to find sponsors to offer some kind of stipend to make it easier for students to participate. We are even looking at how Red Hat can itself be one of these sponsoring organizations, outside of the internship program Red Hat continues to run.

Thank you, Google, for getting us started. We will take it from here.

Microsoft Update KB977165 triggering widespread BSOD

One of Microsoft’s “Patch Tuesday” security fixes is triggering a widespread “Blue Screen of Death” problem.  The cause is not the update itself, but an existing infection.  So far, reports suggest that this problem affects Windows XP and Windows Vista.

Once the update is applied and the system rebooted, Windows will bluescreen at boot.  When booted to Safe Mode, the system will freeze.

Removing the update from the Windows Recovery Console or using live media will get the system booting again, at least until the update is reapplied.

I have found that the root cause is an infection of %System32%\drivers\atapi.sys, and that replacing this file with a clean version will get the system booting normally.

This is not the first time that an infection hitting atapi.sys has caused updates to trigger bluescreens.  If you are running Windows and have not yet applied this update, make sure you scan your computer thoroughly for infections before applying this update.  If you are experiencing this problem, get your computer to a professional that can replace the infected atapi.sys and clean any other malware from your computer.

References:

http://isc.sans.org/diary.html?storyid=8209

http://social.answers.microsoft.com/Forums/en-US/vistawu/thread/73cea559-ebbd-4274-96bc-e292b69f2fd1

Detailed Repair Instructions

Using the Windows XP Recovery Console

1. Boot from your Windows installation CD

Insert your Windows installation CD and boot your computer. If your computer is not set to boot from CD first, you may need to reconfigure your BIOS or press a boot menu key (often F12, F8 or Esc). If you are unsure of how to do this, consult your favorite geek. As soon as the boot starts, you should see a message like “Press any key to boot from CD…” – press a key.

2. Start the Recovery Console

After the CD loads (it may take a minute), you will be presented with a few choices. One of these options is to start a recovery by pressing “R”. Press “R” to launch the Recovery Console.

* You may be asked to choose a Windows installation. If so, choose the damaged installation (probably “1″).
* You may be prompted for the Administrator password. If you do not have one, press “Enter”.

3. Identify your CD drive letter

You should now be at the command prompt. Enter the following command:

map

Look for the drive letter for your CD drive. It may look something like this:

D: \Device\CdRom0

In this case, your CD drive is “D:”.

4. Replace ATAPI.SYS

Enter the following, replacing “D:” with your CD drive:

cd system32\drivers
ren atapi.sys atapi.old
expand D:\i386\atapi.sy_

You should see the message “1 file(s) expanded.” – this indicates you have succeeded.

5. Reboot and scan for malware

Reboot your computer. With a little luck, your computer will now boot normally. Because this problem is caused by malware, you should immediately scan your computer with up-to-date antivirus software.

UPDATE:

An atapi.sys infection may not be the only cause of this blue screen. While it does seem to be the most common cause, other infected drivers or drivers that make incorrect references to the updated kernel bits may also cause blue screens after this update is applied. Make sure you scan any computer with up-to-date antivirus software that can detect rootkits and check for updated drivers for your computer before applying this update.

UPDATE 2:

I have placed these instructions on my wiki.  Any further changes will be posted there.

On Borrowed Time: The Threat of Ransomware

“Ransomware” is a type of malware that holds files or computer operations for ransom.  In the most common scenario, ransomware will encrypt files on an infected computer and demand that the user pay for the decryption key.

Ransomware presents an unusual threat in that simply removing it from the computer does not solve the problem.  When files have been encrypted, removing the ransomware does not make them available again.  The files must be decrypted.

We have been extremely lucky so far.  Most ransomware uses vulnerable encryption, like a simple XOR cipher, or a common key that need only be compromised once and then distributed to affected users.  The distribution of ransomware has also fallen short of that of other threats like scareware.  The number of people affected by ransomware has so far been small, and security researchers have been able to distribute unlocking tools capable of defeating the ransomware, but how long will we be so lucky?

It may only be a matter of time until a more sophisticated, widespread ransomware assault hits the ill-prepared.  When ransomware uses strong encryption and uses unique keys for each victim, security researchers may be unable to offer unlocking tools and a victim’s only recourse would be to pay the ransom.  When a widespread attack hits, the damage could be devastating, and the returns for the attackers would certainly provide inspiration and funding for further attacks.

Some ransomware uses SMS short codes to take payments, which may allow attackers to hide the final billing amount or apply recurring charges and may allow panicked and unsuspecting minors to unknowingly make the payment without first alerting their parents.  Introducing mobile providers into the mix may also affect the ability of the victim to recover the charges.

Scareware distributors have already figured out successful models, their threats are already close to the behavior of ransomware, and they certainly have the resources to develop more advanced ransomware.  Perhaps scareware can serve as a preview into what ransomware may do in the future.

The protection is the same simple, long-standing advice: backups.  If the important stuff is backed up, then a computer infected with ransomware can be cleaned and returned to service without concern for encrypted files.  If you find yourself infected with ransomware and do not have backups, find a computer service company with security expertise that may be able to recover your locked data.  If you have paid the ransom, notify your credit card company or mobile carrier and get your computer cleaned by a professional as quickly as possible.

If you do not have a backup routine, now is the time to create one.  You may be on borrowed time.

Defending Windows with Application Whitelisting

The SANS Internet Storm Center recently featured a post about the increasingly stubborn fake anti-malware “scareware” that has been remarkably successful at infecting machines and convincing people to purchase the fake software.

http://isc.sans.org/diary.html?storyid=7066

Among the comments on that post, others who have encountered this kind of malware questioned what protection measures might be effective. Of course, the common ideas of fingerprinting the malware by filename or checksum came up, as did potential ideas for hardening the operating system in small ways. Unfortunately, this malware has already proven that those measures are not enough. This malware changes too fast for fingerprinting, heuristics are unreliable, and improvements in privilege separation in Windows have been ineffective at blocking this malware.

Removal of this malware can be a tedious and time-consuming task. I have used Fedora Live media or host systems to perform manual cleaning, then spent hours repairing the damage. If a system is infected, I recommend wiping and reloading the system (as I recommend with any infection on any operating system), but it is much easier to prevent infection in the first place. So, if traditional methods are ineffective, what do you do?

An alternative approach that does work against this and most other malware is application whitelisting. In this post, I will run through a quick-start guide to configuring the application whitelisting that is already available in Windows XP and newer releases. There are also more powerful third-party options, and similar capabilities are available for other operating systems.

Application whitelisting is not for everyone, but if you manage a large number of computers that need to be defended, it is definitely worth considering.

Application Whitelisting

Application whitelisting allows an administrator to restrict what programs may run on a computer to a trusted list, instead of a normal configuration where all programs are allowed unless explicitly blocked. This is a highly effective way to block malware and unwanted programs from being installed or used on the system.

The configuration outlined below is ideal for office setups where most users run as restricted users and only a few people may have administrative access. When set up on a domain, this can dramatically reduce the threat of malware, but it does take a lot of freedom of choice away from the users and increases the administrative burden. Running as an administrator bypasses the protection of this configuration.

Windows XP and later have built-in support for application whitelisting. This support is not as robust as that provided by third-party application whitelisting products, but can still be used effectively. Prior to Windows 7, this feature is available as “Software Restriction Policies”. In Windows 7 and later, it is available as “AppLocker”.

Software Restriction Policies

Software Restriction Policies is a system policy feature that can be configured through local system policies or through Group Policy.

To configure Software Restriction Policies as part of Group Policy:

  1. Launch gpedit.msc (on servers, use the Group Policy management tools; to edit local policy instead, use secpol.msc)
  2. Select “Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies”
  3. In the “Actions” menu, choose “New Software Restriction Policies”
  4. With “Software Restriction Policies” selected, double-click “Enforcement” in the right pane
  5. Enforce the policy for “All software files” and “All users except local administrators” and hit “OK”
  6. Double-click on “Designated File Types”
  7. Select the “LNK” extension and hit “Delete” – this allows the Start Menu and Desktop shortcuts to work normally
  8. Hit “OK”
  9. Under “Additional Rules”, you can edit the whitelist with paths, hashes, certificates and Internet zones
    By default, the Windows installation and system folders will be unrestricted, as will “Program Files”
  10. Select “Security Levels”
  11. Right-click on “Disallowed” and select “Set as default”, then click “Yes” when prompted to confirm the change

With these settings, administrators will continue to be unrestricted, while regular users will only be able to run programs that have been installed under the Windows installation folder (typically “C:\WINDOWS”) or under “Program Files”. They will be able to launch those programs using shortcuts. Administrators must handle program installation on behalf of the system’s users.

Network Shares and Mapped Drives

When adding rules for network shares and mapped drives, you must use the UNC path in the rule. Using the mapped drive letter will not work.

More Information

More information on Software Restriction Policies is available from Microsoft TechNet at:

http://technet.microsoft.com/en-us/library/bb457006.aspx