Hello All
I have a question about the Firefox 3.0.18
Is it possible that Firefox (downloaded via yast from OpenSuse repository) recently has been equipped, infected with a BACKDOOR, TROJAN HORSE???
Scenario:
As long as i only startup Firefox everything is ok. This seems very logical, cause the firewall shuts out all incomming trafic.
As soon as I enter an url, and the internet page start to appear on screen, the **** happens… When receiving a webpage, the firewall allows incomming traffic over the HTTP connection from the webserver BACK into my computer…
Then…within 3-5 minutes, without touched my keyboard or mouse, my harddisk is starting to get VERY busy.
It looks like someone is remotely searching my harddisk for something
This “very busy harddisk-search behaviour” misteriously disappears again when i close Firefox!
Additional Information:
I use the following firefox-plugins
Noscript,1.2.0.4
Flashgot,1.9.6.9
SEO Doctor 1.0 <- switched off
Wedeveloper 1.1.8 <- switched off
Java (SE) runtime version, 1.6.09-bo4
Java Hotspot client (build 16.2-b04, mixed mode)
This is the data from the About Help window in Firefox.
Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.0.18) Gecko/2010020400 SUSE/3.0.18-0.1.1 Firefox/3.0.18.
What have I done so far myself:
Via Yast -> Remove Firefox, reboot and re-installed Firefox again
Do a rootkit checkup with chkroot -> nothing
Do a full virusscan with ClamAc -> clean
Note:
This behaviour does not happen with other browsers (like Konqueror, Opera, Mozilla, Seamonkey)
Questions:
1 Who has any suggestions? what can explain this strange Firefox behaviour?
Can this be caused by one of the Firefox plugins?
How can i “monitor” the Firefox application behaviour?
Is there a way to “look under the hood” to see
What Firefox is starting up on childprocesses?
Which activities are being done by which application, task, daemon on my harddrive during this “strange behaviour?”
If you are referring to Firefox browser PLUGINS, that list i already mentioned in my original posting
I use the following firefox-plugins
Noscript,1.2.0.4
Flashgot,1.9.6.9
SEO Doctor 1.0 <- switched off
Wedeveloper 1.1.8 <- switched off
Java (SE) runtime version, 1.6.09-bo4
Java Hotspot client (build 16.2-b04, mixed mode)
This is the data from the About Help window in Firefox.
Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.0.18) Gecko/2010020400 SUSE/3.0.18-0.1.1 Firefox/3.0.18.
If you are referring to something else then firefox-browser-plugins, please take the time and effort to point exactly out what you mean by the word “add ins” please.
Does anyone else has (non beagle like) suggestions?
Hi
Yes I meant the beagle add-in. Can you open a terminal and run the top
command, this should give you an idea of whats occurring on the system.
Install the httpfox add in and start that to see where the browser is
going.
As soon as I enter an url, and the internet page start to appear on screen, the **** happens…
When receiving a webpage, the firewall allows incomming traffic over the HTTP connection from the webserver BACK into my computer…
I don’t think you should panic just yet: a firewall by definition will let port 80 traffic back to your computer if you have established the connection from your end first. Otherwise, you would never receive the web page you requested in the first place.
The disk drive activity certainly needs explanation (see below), but the network traffic you’re seeing I think is normal.
As for the disk activity - I think this is a FF 3.0 issue: a couple of seconds after it starts, it goes through its local cache and does some form of maintenance which is just stupidly disk-intensive. I noticed a big improvement when I turned off all those RSS feeds (headlines, etc.). I believe there is also a cache setting in Firefox you can tweak.
I noticed that in the 11.2 distro, which has FF 3.5, not 3.0, this is no longer an issue. You could try to install 3.5 from the mozilla repository.
Roger that sir! this is what i understood already myself :-).
As for the disk activity - I think this is a FF 3.0 issue: a couple of seconds after it starts, it goes through its local cache and does some form of maintenance which is just stupidly disk-intensive.
Could be true…
I empty the Firefox all-caches before closing the application. I see a dialog box that asks me this manually…
So - imo - there is no “local cache” anymore after having closed down the Firefox application completely.
I noticed a big improvement when I turned off all those RSS feeds (headlines, etc.). I believe there is also a cache setting in Firefox you can tweak.
I did not use these features in the first place.
I noticed that in the 11.2 distro, which has FF 3.5, not 3.0, this is no longer an issue. You could try to install 3.5 from the mozilla repository.
Thanks for this advise twelveeighty.
I have added the mozilla repository to Yast.
I have installed the “new Firefox” version: Mozilla/5.0 (X11; U; Linux i686; nl; rv:1.9.1.9) Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9
Are you running a 32bit CPU? The ‘686’ version of Firefox is intended for a 32bit machine, while the ‘x86_64’ version is used on 64bit CPU systems. The 686 version will run, in 32bit mode however, but this may be responsible for some of your disk access problems.
Unless you have a specific reason to run the 686 version, I would advise that you get the 64bit versions of all software for performance and overhead issues, provided you have a 64bit CPU. You will see a marked increase in performance.
patmartini wrote:
> You will see a marked increase in performance.
really? have you actually done side by side, controlled, timed test of
which programs and processes?
define “marked increase” please…does 64 take (say) 30% less time
to compile a kernel than does 32, or what?
i ask because i know that SOME things done in 64 will be slower than
when done in 32 because the extra bit length addresses take longer to
process while there is zero speed advantage to using 64 because of the
way the program is written–so, it is slower…
>patmartini wrote:
>> You will see a marked increase in performance.
>
>really? have you actually done side by side, controlled, timed test of
>which programs and processes?
>
>define “marked increase” please…does 64 take (say) 30% less time
>to compile a kernel than does 32, or what?
>
>i ask because i know that SOME things done in 64 will be slower than
>when done in 32 because the extra bit length addresses take longer to
>process while there is zero speed advantage to using 64 because of the
>way the program is written–so, it is slower…
Sorry, but where do you get that processing 64-bit addresses take longer?
In X86_64 machines, which are superpipelined, it takes 1 clock tick
either way. And the memory interface is 128/256-bit already.