User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:188.8.131.52) Gecko/20080404 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:220.127.116.11) Gecko/20080404 Firefox/18.104.22.168 Hello, Vietnamese Language Pack 2.0 at http://addons.mozilla.org/firefox/addon/5954 has Xorer trojan. All help pages (*.xhtml) are malicious script right after </html>: <script src="http://%6A%73..."></script> Reproducible: Always Steps to Reproduce: 1. Go to http://addons.mozilla.org/firefox/addon/5954 2. Save the xpi file 3. Scan that file with Avast, Kaspersky or any antivirus you have, 2/3 will detect it. Expected Results: remove the virus
CC'ing the author as well.
I've admin-disabled (author can't update) the langpack until we can investigate this further.
Link to xpi for when cache expires and it stops showing up on public pages: http://releases.mozilla.org/pub/mozilla.org/addons/5954/vietnamese_language_pack-2.0-fx-win.xpi
clamscan says: vietnamese_language_pack-2.0-fx-win.xpi: HTML.Xorer FOUND The file is dated February 18, the virus signature is date April 14, so we apparently had this in the wild for about 2 months before the scanners were detecting it. I think this needs to be nuked from the UI on the addons site first by an addons admin. If I nuke it from staging the app will just put it back.
and I see fligtar already did that, I midaired with him.
FWIW, I think we're talking about <http://www.pandasecurity.com/homeusers/security-info/about-malware/encyclopedia/overview.aspx?idvirus=189095&sitepanda=particulares>, right?
https://addons.mozilla.org/de/firefox/browse/type:3 still links to it, btw.
The signature I found that said April 14 on it was HTML.Xorer.A. The one you just found is much more likely to be a match, and the window looks much smaller there.
With info from Panda security, I think it just because the author's local network was infected with the virus, so it modified html files. The main virus is a Win32 program. The infected code just display annoying banner but it can't propagate. I think we might just remove the script and everything backs ok.
Just FYI, I scanned the entire addons tree last night with the current virus defs and that was the only file found to be infected with anything.
I thought we were scanning all the uploads -- did it slip by before the virus definitions were updated to include HTML.Xorer? Maybe we need to rescan after every definition update?
(In reply to comment #8) > https://addons.mozilla.org/de/firefox/browse/type:3 still links to it, btw. After the cache expired, that's gone now AFAICT.
Yes, thanks. Should we have nuked the caches for this, and can we?
(In reply to comment #14) > Yes, thanks. Should we have nuked the caches for this, and can we? IT can, and for critical things like this I suggest we do it in the future when we need immediate effect. It will put more load on the app cluster but it's temporary until the caches refill. However, since Justin disabled the add-on, I am quite sure the download stopped working immediately in spite of the link being shown, so it didn't do harm (more than possibly confusing the users clicking it in vain, of course).
I don't know what exactly happens when you disable an add-on, but as the langpacks page links directly to the https://addons.mozilla.org/de/firefox/downloads/file/22560/furlan_language_pack-22.214.171.124-fx.xpi etc file pages, I don't think this is necessarily one go. I don't have the old file link, so I can't tell. But that's somewhat off-topic to this bug here. Looking forward, I guess there are a few extra bugs to file? I guess the infected file on http://releases.mozilla.org/pub/mozilla.org/addons/5954/ should move into a even more restricted area? Do we need a bug for scanning the add-ons for updated signatures? I guess we need a bug on the langpack page offering all kinds of packs independent of fx version. Is there a trivial review thing we can do to catch infected langpacks early? Jasper, please make sure that your system is cleaned up, remove the offending html parts and try to get the updated version back up on AMO?
Since we seem to have determined it wasn't malicious on the part of the author, I've changed the add-on status to be in the sandbox and deleted both files. Jasper, please upload a new version without the virus and let us know and we'll check it out before pushing it public again. Dave, please delete the files again - they shouldn't come back now.
(In reply to comment #12) > I thought we were scanning all the uploads -- did it slip by before the virus > definitions were updated to include HTML.Xorer? Yes, that was explained in comment 5. > Maybe we need to rescan after every definition update? Ideally, yes, except that we get new definitions on average every 6 hours or so and it takes over a week to virus scan the entire ftp server. Getting monthly scans is in the plan for the new stage server once we get it working. (In reply to comment #17) > Dave, please delete the files again - they shouldn't come back now. It should have deleted it automatically when you moved it to the sandbox. If it didn't, it's a bug.
(In reply to comment #18) > It should have deleted it automatically when you moved it to the sandbox. If > it didn't, it's a bug. > bug 421173 in fact!
OK, file removed from public_staging.
Can we just rescan using the newly added definitions (if that makes things faster), or just scan add-ons to make it go faster? I think the risk level is a fair bit higher for uploaded add-ons and the contrib directories than for the builds pushed out by our tinderboxes, so it'd be good to improve the frequency on the softer targets if we can.
I rescanned the addons tree last night, it took a few hours to run. Don't know how many, it had been going for an hour or two when I went to sleep and it was done when I woke up. Getting a full scan of addons daily would probably be doable.
(In reply to comment #18) > (In reply to comment #12) > > I thought we were scanning all the uploads -- did it slip by before the virus > > definitions were updated to include HTML.Xorer? > > Yes, that was explained in comment 5. > > > Maybe we need to rescan after every definition update? > > Ideally, yes, except that we get new definitions on average every 6 hours or so > and it takes over a week to virus scan the entire ftp server. Getting monthly > scans is in the plan for the new stage server once we get it working. Is there a bug on this?
Filed bug 432736 on blocklisting the infected version
Currently waiting on response from the author, who is CC'd to this bug. I guess if we don't hear anything after a week, we'll call this FIXED and ask Editors to request super-review if they see it come through the queues later.
Was the source of this malicious code found?
Jasper also made a Vietnamese distribution of Firefox, in case you'd like to check it for any issues: Unix: http://jasperlotus.googlepages.com/vi-VN.tar Self-contained EXE: http://jasperlotus.googlepages.com/firefoxportable.exe Description: http://jasperlotus.blogspot.com/2006/11/firefox-20-ting-vit-final.html
Sorry for the inconvenient! I've found that translated help files was modified by a virus, come from China. I'm so busy these days, but I've cleaned up malicious code. The new fresh pack coming soon. Thanks!
FYI (per email I just got from them) McAfee detects this as "W32/Fujacks!htm trojan". (They contacted me for a sample since they didn't have anything called Xorer in their database - turns out they had it, just under a different name).
Hi Jasper, where were the translated help files modified from? Your desktop? Once they were on the Mozilla servers?
(In reply to comment #31) > Hi Jasper, where were the translated help files modified from? Your desktop? > Once they were on the Mozilla servers? Considering that the virus in question is a Windows virus and the machine it's housed on at Mozilla runs Linux, it probably wasn't on our end. We do know that the signature for that virus wasn't in the virus defs for our virus scanner until about 2 weeks after the file was uploaded.
Is there any reason that language packs need a "script" capability at all? I suggest preventing ANY use of scripts, etc., in language packs. In fact, I think language packs should be scanned to permit only specific formats, and forbid anything else. Language packs are a very special case in open source software. Generally, anyone who can speak English (a vast number of people nowadays) can review all other components, but only speakers of particular languages are going to be competent at reviewing a language pack. Since mass peer review is less likely to work for language packs for less-common languages, it'd be better to make it impossible for language packs to do harm in the first place. Anyway, my two cents; hope it helps. You guys have done a lot of great stuff; here's hoping for even better.
(In reply to comment #33) > Is there any reason that language packs need a "script" capability at all? I > suggest preventing ANY use of scripts, etc., in language packs. In fact, I > think language packs should be scanned to permit only specific formats, and > forbid anything else. > No, they shouldn't contain scripts as mentioned in bug 390657 and bug 391705. Official policy is at http://wiki.mozilla.org/Update:Editors/ReviewingGuide#Reviewing_Language_Packs. AMO currently doesn't enforce this policy via software (bug 371210).
From a cursory search through the language pack's source, it looks like only the help files were affected here, and offline help has been removed for Firefox 3 in favor of support.mozilla.org. By the way, if there are unused HTML files in a language pack, do they still pose a risk (i.e., by some old extension trying to load it through a chrome:// URL)?
Removing scripting abilities from language packs would be a major architectural change, maybe we can do that for Mozilla 2. As long as we feeding standard DTDs to the xml parser, they can hook up scripts. The review policy should ask contributors to remove unnecessary files, which is what the compare-packs will show, which is part of the policy. Whether there are proper heuristics to include in something for bug 371210 is a different question, and probably relates to all add-ons, not just language packs. Like, an extension author could try to hide a bad script tag (malicious or not) in a localization DTD at any time, so checking for something like "<(XMLName:)script" could be a good idea.
(In reply to comment #36) > Removing scripting abilities from language packs would be a major > architectural change, maybe we can do that for Mozilla 2. Maybe we can't do much for dtd content, but we can at least make the help viewer content window disable scripts and plugins just in case. Filed bug 432919
Oh! I wonder why I can't upload the new pack? ``Please select a valid add-on type.'' in a red box. I must do it soon because I have no more time!
(In reply to comment #38) > Oh! I wonder why I can't upload the new pack? > ``Please select a valid add-on type.'' in a red box. > I must do it soon because I have no more time! Can you attach it to this bug at least? That way, if you can't upload it yourself, an AMO admin can upload it for you.
(In reply to comment #38) > Oh! I wonder why I can't upload the new pack? > ``Please select a valid add-on type.'' in a red box. > I must do it soon because I have no more time! > Hmm, not sure why you'd get that error, but please attach the .xpi to this bug (click "Add an attachment" above) and if it looks good, we'll upload it and push it public for you.
Those files are not part of the language pack, but merely used for the repackaged builds. At least in the standard builds we do. They are generated, but not packaged, see http://mxr.mozilla.org/mozilla/source/browser/locales/Makefile.in#288, for example. Which is good, otherwise we'd break automatic updates again, those can't stand setting the useragent locale in an add-on pref.
The new version looks good to me. dveditz and axel, please review and make sure everything looks good, if you don't mind.
Since we don't currently have a version of the Vietnamese Language Pack on AMO, I'm going to make the new attached version public on Wednesday if dveditz or axel hasn't reviewed it by then.
That ain't the review policy anywhere else in Mozilla, and I'd rather not make it the one on AMO. Setting deadlines to just do stuff instead isn't the right way to poke for reviews either.
If you're busy, please feel free to ignore the review request - I was just looking for another set of eyes on it to make sure I didn't miss anything. I indicated the deadline because that's when I intend to push it public and if either of you were interested in checking it out before that was done, you'd know when it would happen. Of course if you have any specific concerns about it, I can wait.
Comment on attachment 320114 [details] Vietnamese Language Pack 126.96.36.199 r=dveditz Identical to version 2.0 with the <script> tags removed from help .xhtml files
Comment on attachment 320114 [details] Vietnamese Language Pack 188.8.131.52 Review comments: in regionNames.properties, the 'vi' entry should actually be 'vn'. There is some mismatch in mozapps/xpinstall/xpinstallConfirm.properties, see bug 275629, -itemWarnIntroMultiple -itemWarnIntroSingle +itemWarningIntroMultiple +itemWarningIntroSingle The following files shouldn't be in the vi-VN.jar: 699 07-21-07 19:26 locale/browser/aboutDialog.dtd.bak 2335 10-18-06 20:53 locale/browser/baseMenuOverlay.dtd.bak 17884 07-21-07 19:47 locale/browser/browser.dtd.bak 5561 07-21-07 19:54 locale/browser/browser.properties.bak 1673 10-26-06 21:56 locale/browser/credits.dtd.bak
Axel: are those a regression of some sort, vs. the infected version people have installed today?
Those are not regressions. But: as long as bug 313453 is out there, we won't update existing users of that language pack. So I'd rather get this up without bugs, then getting it up with bugs again.
Jasper, can you make another xpi with the issues in comment #52 addressed please?
Created attachment 321234 [details] New 2.00.14 pack New xpi with the issues in comment #52 addressed!
Comment on attachment 321234 [details] New 2.00.14 pack Putting this into my review queue again.
@Vietnamese guys: Nhân tiện, chúng ta có thể bắt đầu dịch Firefox 3 luôn không? Phiên bản mới này mình thấy có nhiều điểm khá thú vị. Thật tiếc là người Việt chúng ta cũng dùng Firefox khá nhiều mà vẫn chưa có một phiên bản phát hành chính thức trên trang chủ. Nếu bây giờ chúng ta có thể bắt tay vào làm để được phát hành cùng lúc với ngày ra mắt chính thức bản Firefox 3 final thì thật hay. Mình muốn được giúp đỡ Jasper Thái. Hi vọng bạn cũng muốn tổ chức một nhóm để làm, thay vì làm việc đơn lẻ như hiện tại.
Rough translation: (In reply to comment #58) > By the way, can we begin translating Firefox 3 as well? I think > the new version has many great features. It's really sad that > very many of us Vietnamese use Firefox, but there still isn't an > official release [in Vietnamese] at [Mozilla's site]. It would be > great if we could get to work and release a translation by the > time Firefox 3 final is officially released. > > I would like to help you, Jasper Thái. Hopefully you'd also like > to organize a group to do this, instead of by yourself.
Comment on attachment 321234 [details] New 2.00.14 pack This is looking good. Mind uploading that again to AMO and update this bug with the extension URL? Then I'll carry my review over to there, too.
I uploaded the new version and made the add-on public again. Because of an issue with uploading language packs currently, the add-on type was changed to Extension during upload. I'll be able to change it back to Language Pack after our 3.4.3 changes are pushed live tonight. Until then it won't show up on the Dictionaries and Language Packs landing page.
Ok, the add-on type has been changed back to Language Pack (Application) and should show up on the landing page when cache is cleared. Resolving.
VERIFIED, just checked. The advanced search stuff seems to be having layout issues, I hope this is just the css not being out of the cache yet.
I'm requesting a CVS account. Please vouch for me. I'm currently working on FF3. Thanks! Details: https://bugzilla.mozilla.org/show_bug.cgi?id=356527
The content of attachment 375531 [details] has been deleted by Dave Miller [:justdave] <email@example.com> who provided the following reason: Windows EXE file, unrelated to bug The token used to delete this attachment was generated at 2009-05-03 14:34:22 PDT.