Bug 517325 - Suspected malware on a recent Fedora 11 DVD ISO
Summary: Suspected malware on a recent Fedora 11 DVD ISO
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 11
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-13 14:15 UTC by Martin Gregorie
Modified: 2014-03-17 03:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-20 20:03:19 UTC


Attachments (Terms of Use)

Description Martin Gregorie 2009-08-13 14:15:52 UTC
Description of problem: 
I downloaded the F11 DVD ISO in Tuesday, 11th August 2009, burnt it and ran a
media check. It passed.

Yesterday, Wed 12th, I installed it on a new WD Caviar SE 160 GB drive. This completed successfully and booted into the new install and restored my /home partition from a backup.

After a while I noticed that the box sounded as if the disk was hitting its
limit stop about once a second though performance was't affected, and that an
Icon I'd never seen called 'hammer' and showing a white rectangle covered in
black 1s and 0s had appeared on my desktop. It said it was unverified, so I deleted it. Meanwhile the banging sound woulodn't stop, so I rebooted the system. This made it go away until I opened a terminal window, when the noise
started again but louder. 

This time I did a second reinstall, reformatting all partitions except /home (which I didn't reformat) because my customisation wasn't right [1]. Again, all went well, but after the reboot the hammering came back louder than ever with a 'musical' accompaniment as soon as I opened a terminal window.   

During all this the machine was never connected to a network.

At this time I did a third reinstall, this time from a Fedora 10 DVD and again reformatted all partitions to ext3, and again restoring the contents of /home,
/var/named and /var/spool/mail from the same backup. This is currently running happily and without any sign of hammering.

[1] I needed named to bring my network up because this host is the DNS server for my LAN. I note that PackageKit can't have its sources list extended BUT why can't it pick up packages from its source ISO and why doesn't the installer let package selection be revisited before starting the install? Every other activity can be revisited before moving on, so why not this as well?


Version-Release number of selected component (if applicable):
The DVD ISO for Fedora 11 as at Tuesday, 11th August 2009

How reproducible:
I imagine if I did another clean reinstall the problem would appear for a third time.

Steps to Reproduce:
1. Download the DVD ISO that was on offer during the 11th August 2009
2. Burn it to a disk
3. Do a clean install from it.
  
Actual results:
 A successful install, but contaminated foth this 'hammer' thing.

Expected results:
 A successful install WITHOUT the 'hammer' thing. 

Additional info:
 -- You want the DVD or the ISO?

Comment 1 Andre Robatino 2009-08-13 21:56:16 UTC
Try using the rawread script from

http://www.troubleshooters.com/linux/coasterless.htm

to check the checksum on the disc as follows:

./rawread /dev/dvd | sha256sum

and compare with the correct value, which for Fedora-11-i386-DVD.iso is

6e812e782e52b536c0307bb26b3c244e1c42b644235f5a4b242786b1ef375358

Or if you still have the ISO on the HD, just run sha256sum on that.  The mediacheck only protects against natural corruption, not a deliberate fake (which is why I always download the signed CHECKSUM file and run gpg --verify on it).

Comment 2 Martin Gregorie 2009-08-14 14:04:53 UTC
I founfd a rawread script (it runs isoinfo and passed those parameters to dd) and generated the checksum as requested. 

Its the same as the one you posted.

Comment 3 Jens Petersen 2009-10-13 09:07:55 UTC
Do you have a screenshot of the "hammer"?

Comment 4 Martin Gregorie 2009-10-13 09:53:11 UTC
Unfortunately, no, I don't have a screen shot.

The icon was a white portrait-style rectangle, possibly with a thin black border. It contained 3-4 lines, each containing black ones and zeros. I called it 'hammer' because that was the icon caption.

Comment 5 Andre Robatino 2009-10-13 16:54:25 UTC
[andre@compaq-pc tmp]$ strings Fedora-11-i386-DVD.iso | grep hammer
- Stop hammering stuff on update of chroot environment
- Stop hammering stuff on update of chroot environment
- Stop hammering stuff on update of chroot environment
- Stop hammering stuff on update of chroot environment
hammerlock.py
hammerlock.pyc
hammerlock.pyo
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
hammerhead
/usr/src/kernels/2.6.29.4-167.fc11.i686.PAE/arch/avr32/boards/hammerhead/
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
hammerhead
/usr/src/kernels/2.6.29.4-167.fc11.i586/arch/avr32/boards/hammerhead/
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
   drm-i915-apply-a-big-hammer-to-865-gem-object.patch
- merge changes in from -6hammer
- merge changes in from -6hammer
- fix mysql_config on hammer
- fix mysql_config on hammer
- fix mysql_config on hammer
- fix mysql_config on hammer
- Merge in hammer changes, rebuild
- Merge in hammer changes, rebuild
- Merge in hammer changes, rebuild
Elliot Lee <sopwith@redhat.com> 0.9.6b-29hammer.3
- Merge fixes from previous hammer packages, including general x86-64 and
Elliot Lee <sopwith@redhat.com> 0.9.6b-29hammer.3
- Merge fixes from previous hammer packages, including general x86-64 and
Elliot Lee <sopwith@redhat.com> 0.9.6b-29hammer.3
- Merge fixes from previous hammer packages, including general x86-64 and
- hammer events revised.
hammer
/usr/share/oprofile/x86-64/hammer/
- hammer events revised.
Jeremy Katz <katzj@redhat.com> 1.4.24-6hammer
hammer.png
- Merged patch from Karsten Hopp <karsten@redhat.de> from 2.2.1-17hammer to
- Merged patch from Karsten Hopp <karsten@redhat.de> from 2.2.1-17hammer to
- Merged patch from Karsten Hopp <karsten@redhat.de> from 2.2.1-17hammer to
Than Ngo <than@redhat.com> 3.0.5-17hammer
Than Ngo <than@redhat.com> 3.0.5-17hammer
Than Ngo <than@redhat.com> 3.0.5-17hammer
- Fix leaking fd for loadkeys with a big hammer (#501368)
- Merge changes from 8.0-hammer
- Merged patch from Karsten Hopp <karsten@redhat.de> from 2.2.1-17hammer to
Phil Knirsch <pknirsch@redhat.com> 2.11r-10hammer.3
Elliot Lee <sopwith@redhat.com> 2.11r-10hammer.2
Than Ngo <than@redhat.com> 2.11r-10hammer.1
Bernhard Rosenkraenzer <bero@redhat.com> 2.11r-10hammer
- Port to hammer
[andre@compaq-pc tmp]$

Comment 6 Josh Bressers 2009-10-13 19:00:56 UTC
It would make the most sense for you to re-install F11, and not restore anything. It is more likely this is an issue with something in your home directory and not F11.

Comment 7 Martin Gregorie 2009-10-13 19:36:37 UTC
I'd respectfully disagree with that. I've never written or installed anything resembling this hammer thing. In any case, if it was crud that came in with the /home restore, why hasn't it affected F10?

There is nothing in ~/bin in my usual login directory apart from a script wrapper for diff and the hammering started before I'd got round to adding the symlink to /usr/local/bin. After a fresh install I delete the /usr/local structure and replace it with a symlink to 
/home/local.

However, in this case the hammering started before I'd done anything except the /home restore and trying to get the network up in order to run 'yum upgrade' - this is normally the first thing I do after a clean install. 

In this case I wanted to restore the /home partition before running yum. Doing stuff in this order was intended to leave my new disk as it would have been if the clean install was to an older disk. Normally /home is already there because this partition is never reformatted.

Comment 8 Bill Nottingham 2010-01-20 20:03:19 UTC
Sorry about the delayed response. I'm not sure what to say here - this is the only report we've seen anywhere, and we have an install base of many many thousands. Furthermore, we can't reproduce this. At the moment, I don't think we have anoy other course as to close this as WORKSFORME.


Note You need to log in before you can comment on or make changes to this bug.