He starts off by saying the cache folder is known - actually the folder name has random characters (last 3 in Firefox, first 8 in Mozilla), so that's not true - you have at best a 1 in 17000 of guessing it.
Then he talks about the user opening file:// URLs - what would cause the user to do that? If you have to tell the user "please type this URL into your address bar", that's not much of an exploit. Links to file:// URLs from http:// URLs don't work.
And as someone else pointed out, the script running in a page from a file:// URL has pretty much the same permissions as a script running in a remote page anyway - there is no "local zone" concept in Mozilla/Firefox.
Certainly sounds like there may be a bug or two described there, but I don't see an exploit.
The bug was actually fixed last month. The fix didn't make it into 1.7 though because the change caused another problem - that problem is now being worked on. When the secondary problem is fixed, the combined fix should get into a 1.7.1 version and/or Firefox 1.0.
If you want it to work right now, either apply the patch to the 1.7 code and compile it yourself, or grab a trunk nightly build.
Pretty much all of the new stuff in Mozilla 1.7 is core development, or Firefox/Thunderbird/Chatzilla development that can also be applied to the suite without significant extra effort.
In terms of front-end work, Firefox/Thunderbird development is going much faster than the suite, where development has pretty much stopped.
Re:Why new features if they have an extension mode
on
Mozilla 1.8 Alpha Released
·
· Score: 4, Informative
They didn't add an "FTP client" - they added UI to allow FTP upload. The FTP back-end is useful for other stuff, and was already present - adding the menu command wasn't a huge thing.
bl.spamcop.net isn't a host - it's never been possible to resolve it. To get a result, you have to look up something like 1.0.0.127.bl.spamcop.net. The DNS for spamcop.net is handled by Akamai (because Akamai handle some of the website processing), but the DNS for the BL isn't - Akamai's servers delegate that to a server hosted at Spamcop, and a few mirrors elsewhere.
The Akamai issue did indeed affect www.spamcop.net, but I don't think your problems are related to that.
ISPs can already see exactly whose machine has been trojaned from the time and IP. Checking their logs to find that info is trivial - the tricky part is getting the user to patch/clean their computer. Knowing the email address of the person whose machine is trojaned doesn't really help the recipient.
Having correct sender addresses would be nice, and would force spammers and virus writers to adapt somewhat. The question is whether the effort of implementing it is worth it for the gains available.
The envelope-sender can be just as easily spoofed as the From: header. If you're sending email out through your ISP or corporate email relay, that may well check that the host (or the whole address) is correct.
If you do as most spammers do and connect directly to the receiving server, then you can feed it whatever you like in the envelope sender, and it has no way of checking whether it's genuine or not. This is what stuff like SPF can help with, but as things are currently implemented just about everywhere, the envelope-sender addresses on spam and viruses are generally forged.
tgma apparently did RTFA, as they say "I commend the original article". tgma is complaining about the slashdot story, where the submitter has introduced a mention of "Russian spyware sites".
No. MyDoom (and most other recent viruses) don't use your MS address book particularly - they search the entire hard drive for a whole range of files and pick up email addresses from all of them. They also use their own SMTP code to send emails.
Re:But No One's mentioned the most important featu
on
Mozilla 1.6 Released
·
· Score: 1
Is it really only because it's too scary for people? The implementation details are possibly scary (and if not, then boring) to most, but stuff like "10% improvement in laying out web pages" isn't.
My impression that it's more because when release note folks are looking through a big list of bug summaries for bugs that have been fixed, they understand things like "about:about", but not stuff like "XUL style attributes should use recycled CSS parsers" or "remove nav4algorithm code in nsStyleUtil.cpp".
I'm sure cool changes to the core engine could be added to the release notes if someone who understood the core engine stuff wrote them up in English and pushed them at the right person at the right time (or they could be added after the release notes are initially published...)
Re-reading the article won't help, as the article isn't correct on that point. If you check a technical write-up, e.g. Symantec's, you can see that this worm actually arrives as a.zip file.
So, users need to do something like click on the attachment, wait for Winzip to appear, and then double-click on the executable file (the type will be displayed) in the Winzip interface to run it (and if they're using a version of Winzip that's not ancient, they'll get a Winzip pop-up pointing out that the file is executable and asking for confirmation that they want to run it).
The claimed sender email address doesn't have much to do with anything - no hacking is required to use someone else's email address.
Owners of machines getting hacked (or just being badly configured so they can be abused without being hacked), from what I just read elsewhere and looking at the bill, won't be paying anything. The penalty is against those that originate the spam and not against those conveying it (legitimately or not).
Alternatively, you give the spammer an encrypted list, they generate a bunch of addresses at random and encrypt each one, pick out the ones that match, and they have a list of valid addresses.
The spammers are already generating random addresses and trying them remotely on the recipient's mail servers. Encrypting and checking locally against a list is much less effort.
When Netscape made changes to the Mozilla code, they contributed those changes back to Mozilla, which the MPL requires. However, they didn't release the code for the AIM built into Netscape.
Sounds like Lindows/NVU will do the same - changes made to the Mozilla Composer code will be contributed back into Mozilla, but new code written for other parts of the product won't be.
As you say, SoBig didn't damage anything much, it just spread and caused secondary damage. For that, all it needs to be able to do is save itself to disk somewhere and be able to open sockets to the internet. AFAIK, Sobig runs fine with user rights on Windows boxes, and I can't see any reason why it shouldn't do the same on a Linux box.
Most spam originates in the US currently (that is, it is people in the US causing it to be sent, although most of it comes via computers in other countries), but it's mostly not US companies, it's individuals. The stuff for stocks and property is usually a scam, and the actual stocks and any real property are also victims of the situation. The stuff for herbal/generic viagra/vicodin etc etc could equally well be shipped internationally.
The big time spammers are already involved in various illegal activities, but the enforcement is pretty much non-existant. If the FBI can't get them for the illegal activies, what chance is there of some other agency stopping them hitting email addresses on a list?
They do? Some Swen emails do contain an exploit for an old security flaw which doesn't exist in recent versions, but Swen operates primarily as a trojan. Same with Sobig.f. These things are spreading by sending messages saying things like "the attachment is an important security fix, please run it" and people are running them. Heck, one of the previous worm/trojans sent a message saying "this attachment will protect you from viruses. It may trigger anti-virus protection, so you should disable your anti-virus before you run it" - and people duly disabled their anti-virus software and then ran the trojan. The trojan/worms don't need any special privileges either - regular user rights are ok. Most of the big "viruses" aren't actually viruses, they are trojan/worms - you run them, they send themselves to other people who run them, and they spread...
The reason there aren't Linux "viruses" is because there are less Linux users, more of those users understand they shouldn't run random executables that get sent to them, and because of binary incompatibilities.
I've just found out that the <BR> part of that bug was not actually fixed - the release notes are incorrect (or at least were incorrect - they're being changed to only say "<HR>" and not "<HR> and <BR>")
If the <BR> part had been fixed, it would mean you could use CSS3 to do something like:
and your CSS-generated content of "foo", inserted before your <br> tag, would appear in blue. Not something you're going to use every day. And you can't yet, because only the <HR> part of the bug was actually fixed. Anyone desperately waiting to style their line breaks will have to wait a bit longer for Mozilla to support it.
It's nothing to do with showing the line breaks in Composer.
Although it was something they had hoped for, they didn't "clearly specify" that it "must" be included in 1.5. You can look at the document history for the roadmap using the link at the bottom of the page.
The original (April 2nd) version of the 1.4-and-beyond roadmap said: "We're only pointing the way here. The detailed plan of attack should be developed in the newsgroups and via Bugzilla. Whether we'll be able to switch to Phoenix by the Mozilla 1.5 final milestone remains to be seen."
That text was then updated in July to read: "It's clear now that we will not be able to switch to Mozilla Firebird by the Mozilla 1.5 final milestone. Instead, we expect Mozilla 1.5 to coincide with Mozilla Firebird 0.7. But we intend to implement the new application architecture in the next several milestones, till most of the community is won over to the new apps."
The standard Mozilla builds only come with the US English dictionary but you can get a UK English dictionary (and dictionaries for around 20 other languages) from www.mozcafe.com/download
If "name_of_plugin" is something closed source which is only distributed as a binary, you'll hit the same problem. A quick google search turns up Gentoo users having problems with RealPlayer.
If the plugin was open source, then the issue wouldn't exist for other people either.
If you want zealotry, this would be a good opportunity for Windows users who have never heard of a compiler to point and laugh...
One of the reasons that Mozilla doesn't score a few points higher is that some of his "CSS2" tests are actually taken from the draft CSS3 specs. Mozilla intentionally doesn't implement draft CSS3 stuff using the proposed CSS3 names. Opera does, which means if the proposal changes before it becomes standard, then Opera will then be in a position of having to choose between breaking compatibility with their previous version and following the standard.
The CSS3 parts of the test are: http://www.xs4all.nl/~ppk/css2tests/box.html http://www.xs4all.nl/~ppk/css2tests/display.html #i nlineblock
Also, he seems to be comparing Opera 7.0 and Mozilla 1.1 - both browsers have moved forward since the site was written.
No, there isn't some hidden Windows mechanism that auto-launches items within zip files. For this worm to propagate, the user has to open the zip file and then run the pif file within it.
And whether or not you have Outlook or Outlook Express installed makes no difference. The worm has its own SMTP engine - once the worm is running, all it needs is for your computer to be connected to the internet and it will propagate itself.
Maybe the fast spread of this worm will go some way to dispel the myth that all these viruses are due to security flaws in Outlook and OE. If you put the same users that are running this worm in front of a Linux or Mac system where it was possible for them to open and run attachments with a couple of clicks, this kind of thing would work just as well.
not entirely true - Firebird is based on the trunk of the Mozilla tree. Therefore, it was based on the 1.4beta code base, but it's now based on the pre-1.5alpha code base. The Mozilla 1.4 code was branched/forked off a short time after 1.4beta.
So, all the good stuff that is in Mozilla 1.4 will also be in Firebird, but Firebird nightlies won't have the stability of 1.4 because they've got a whole bunch of new pre-1.5alpha stuff as well.
Slashdot Mirror
But is it actually an exploit?
He starts off by saying the cache folder is known - actually the folder name has random characters (last 3 in Firefox, first 8 in Mozilla), so that's not true - you have at best a 1 in 17000 of guessing it.
Then he talks about the user opening file:// URLs - what would cause the user to do that? If you have to tell the user "please type this URL into your address bar", that's not much of an exploit. Links to file:// URLs from http:// URLs don't work.
And as someone else pointed out, the script running in a page from a file:// URL has pretty much the same permissions as a script running in a remote page anyway - there is no "local zone" concept in Mozilla/Firefox.
Certainly sounds like there may be a bug or two described there, but I don't see an exploit.
The bug was actually fixed last month. The fix didn't make it into 1.7 though because the change caused another problem - that problem is now being worked on. When the secondary problem is fixed, the combined fix should get into a 1.7.1 version and/or Firefox 1.0.
If you want it to work right now, either apply the patch to the 1.7 code and compile it yourself, or grab a trunk nightly build.
Pretty much all of the new stuff in Mozilla 1.7 is core development, or Firefox/Thunderbird/Chatzilla development that can also be applied to the suite without significant extra effort.
In terms of front-end work, Firefox/Thunderbird development is going much faster than the suite, where development has pretty much stopped.
They didn't add an "FTP client" - they added UI to allow FTP upload. The FTP back-end is useful for other stuff, and was already present - adding the menu command wasn't a huge thing.
bl.spamcop.net isn't a host - it's never been possible to resolve it. To get a result, you have to look up something like 1.0.0.127.bl.spamcop.net. The DNS for spamcop.net is handled by Akamai (because Akamai handle some of the website processing), but the DNS for the BL isn't - Akamai's servers delegate that to a server hosted at Spamcop, and a few mirrors elsewhere.
The Akamai issue did indeed affect www.spamcop.net, but I don't think your problems are related to that.
ISPs can already see exactly whose machine has been trojaned from the time and IP. Checking their logs to find that info is trivial - the tricky part is getting the user to patch/clean their computer. Knowing the email address of the person whose machine is trojaned doesn't really help the recipient.
Having correct sender addresses would be nice, and would force spammers and virus writers to adapt somewhat. The question is whether the effort of implementing it is worth it for the gains available.
The envelope-sender can be just as easily spoofed as the From: header. If you're sending email out through your ISP or corporate email relay, that may well check that the host (or the whole address) is correct.
If you do as most spammers do and connect directly to the receiving server, then you can feed it whatever you like in the envelope sender, and it has no way of checking whether it's genuine or not. This is what stuff like SPF can help with, but as things are currently implemented just about everywhere, the envelope-sender addresses on spam and viruses are generally forged.
tgma apparently did RTFA, as they say "I commend the original article". tgma is complaining about the slashdot story, where the submitter has introduced a mention of "Russian spyware sites".
You may think that, but (as various other comments have already pointed out) it's not what RFC 1738 says:
"3.3. HTTP
... An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
.. . No user name or password is allowed."
Any URLs broken by this change weren't RFC-compliant.
No. MyDoom (and most other recent viruses) don't use your MS address book particularly - they search the entire hard drive for a whole range of files and pick up email addresses from all of them. They also use their own SMTP code to send emails.
Is it really only because it's too scary for people? The implementation details are possibly scary (and if not, then boring) to most, but stuff like "10% improvement in laying out web pages" isn't.
My impression that it's more because when release note folks are looking through a big list of bug summaries for bugs that have been fixed, they understand things like "about:about", but not stuff like "XUL style attributes should use recycled CSS parsers" or "remove nav4algorithm code in nsStyleUtil.cpp".
I'm sure cool changes to the core engine could be added to the release notes if someone who understood the core engine stuff wrote them up in English and pushed them at the right person at the right time (or they could be added after the release notes are initially published...)
Re-reading the article won't help, as the article isn't correct on that point. If you check a technical write-up, e.g. Symantec's, you can see that this worm actually arrives as a .zip file.
So, users need to do something like click on the attachment, wait for Winzip to appear, and then double-click on the executable file (the type will be displayed) in the Winzip interface to run it (and if they're using a version of Winzip that's not ancient, they'll get a Winzip pop-up pointing out that the file is executable and asking for confirmation that they want to run it).
The problem isn't the software, it's the users.
The claimed sender email address doesn't have much to do with anything - no hacking is required to use someone else's email address.
Owners of machines getting hacked (or just being badly configured so they can be abused without being hacked), from what I just read elsewhere and looking at the bill, won't be paying anything. The penalty is against those that originate the spam and not against those conveying it (legitimately or not).
Alternatively, you give the spammer an encrypted list, they generate a bunch of addresses at random and encrypt each one, pick out the ones that match, and they have a list of valid addresses.
The spammers are already generating random addresses and trying them remotely on the recipient's mail servers. Encrypting and checking locally against a list is much less effort.
And that's why the answer is "Yes".
When Netscape made changes to the Mozilla code, they contributed those changes back to Mozilla, which the MPL requires. However, they didn't release the code for the AIM built into Netscape.
Sounds like Lindows/NVU will do the same - changes made to the Mozilla Composer code will be contributed back into Mozilla, but new code written for other parts of the product won't be.
Why won't they spread it?
As you say, SoBig didn't damage anything much, it just spread and caused secondary damage. For that, all it needs to be able to do is save itself to disk somewhere and be able to open sockets to the internet. AFAIK, Sobig runs fine with user rights on Windows boxes, and I can't see any reason why it shouldn't do the same on a Linux box.
Most spam originates in the US currently (that is, it is people in the US causing it to be sent, although most of it comes via computers in other countries), but it's mostly not US companies, it's individuals. The stuff for stocks and property is usually a scam, and the actual stocks and any real property are also victims of the situation. The stuff for herbal/generic viagra/vicodin etc etc could equally well be shipped internationally.
The big time spammers are already involved in various illegal activities, but the enforcement is pretty much non-existant. If the FBI can't get them for the illegal activies, what chance is there of some other agency stopping them hitting email addresses on a list?
"But trojans have trouble spreading themselves."
They do? Some Swen emails do contain an exploit for an old security flaw which doesn't exist in recent versions, but Swen operates primarily as a trojan. Same with Sobig.f. These things are spreading by sending messages saying things like "the attachment is an important security fix, please run it" and people are running them. Heck, one of the previous worm/trojans sent a message saying "this attachment will protect you from viruses. It may trigger anti-virus protection, so you should disable your anti-virus before you run it" - and people duly disabled their anti-virus software and then ran the trojan. The trojan/worms don't need any special privileges either - regular user rights are ok. Most of the big "viruses" aren't actually viruses, they are trojan/worms - you run them, they send themselves to other people who run them, and they spread...
The reason there aren't Linux "viruses" is because there are less Linux users, more of those users understand they shouldn't run random executables that get sent to them, and because of binary incompatibilities.
It's as weird as it sounds.
I've just found out that the <BR> part of that bug was not actually fixed - the release notes are incorrect (or at least were incorrect - they're being changed to only say "<HR>" and not "<HR> and <BR>")
If the <BR> part had been fixed, it would mean you could use CSS3 to do something like:
br::before { content: "foo"; }
br { color: blue; }
and your CSS-generated content of "foo", inserted before your <br> tag, would appear in blue. Not something you're going to use every day. And you can't yet, because only the <HR> part of the bug was actually fixed. Anyone desperately waiting to style their line breaks will have to wait a bit longer for Mozilla to support it.
It's nothing to do with showing the line breaks in Composer.
Although it was something they had hoped for, they didn't "clearly specify" that it "must" be included in 1.5. You can look at the document history for the roadmap using the link at the bottom of the page.
The original (April 2nd) version of the 1.4-and-beyond roadmap said:
"We're only pointing the way here. The detailed plan of attack should be developed in the newsgroups and via Bugzilla. Whether we'll be able to switch to Phoenix by the Mozilla 1.5 final milestone remains to be seen."
That text was then updated in July to read:
"It's clear now that we will not be able to switch to Mozilla Firebird by the Mozilla 1.5 final milestone. Instead, we expect Mozilla 1.5 to coincide with Mozilla Firebird 0.7. But we intend to implement the new application architecture in the next several milestones, till most of the community is won over to the new apps."
The standard Mozilla builds only come with the US English dictionary but you can get a UK English dictionary (and dictionaries for around 20 other languages) from www.mozcafe.com/download
If "name_of_plugin" is something closed source which is only distributed as a binary, you'll hit the same problem. A quick google search turns up Gentoo users having problems with RealPlayer.
If the plugin was open source, then the issue wouldn't exist for other people either.
If you want zealotry, this would be a good opportunity for Windows users who have never heard of a compiler to point and laugh...
One of the reasons that Mozilla doesn't score a few points higher is that some of his "CSS2" tests are actually taken from the draft CSS3 specs. Mozilla intentionally doesn't implement draft CSS3 stuff using the proposed CSS3 names. Opera does, which means if the proposal changes before it becomes standard, then Opera will then be in a position of having to choose between breaking compatibility with their previous version and following the standard.
l l #i nlineblock
The CSS3 parts of the test are:
http://www.xs4all.nl/~ppk/css2tests/box.htm
http://www.xs4all.nl/~ppk/css2tests/display.htm
Also, he seems to be comparing Opera 7.0 and Mozilla 1.1 - both browsers have moved forward since the site was written.
No, there isn't some hidden Windows mechanism that auto-launches items within zip files. For this worm to propagate, the user has to open the zip file and then run the pif file within it.
And whether or not you have Outlook or Outlook Express installed makes no difference. The worm has its own SMTP engine - once the worm is running, all it needs is for your computer to be connected to the internet and it will propagate itself.
Maybe the fast spread of this worm will go some way to dispel the myth that all these viruses are due to security flaws in Outlook and OE. If you put the same users that are running this worm in front of a Linux or Mac system where it was possible for them to open and run attachments with a couple of clicks, this kind of thing would work just as well.
not entirely true - Firebird is based on the trunk of the Mozilla tree. Therefore, it was based on the 1.4beta code base, but it's now based on the pre-1.5alpha code base. The Mozilla 1.4 code was branched/forked off a short time after 1.4beta.
So, all the good stuff that is in Mozilla 1.4 will also be in Firebird, but Firebird nightlies won't have the stability of 1.4 because they've got a whole bunch of new pre-1.5alpha stuff as well.