395942 - (CVE-2007-5045) QuickTime flaw allows launching default browser with arbitrary parameters on Windows ("quicktime pwns firefox")

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

This was reported at the URL in the URL field. QuickTime seems to have a flaw that allows specially crafted files handled by the plugin to launch the default browser with arbitrary parameters. The examples on that site use the QuickTime flaw to launch Firefox with "-chrome javascript:<code>" to execute arbitrary code, assuming your default browser is Firefox.

The fix for bug 384384 would protect us in this case if QuickTime used the correct system APIs to launch the default browser, but they appear to read the .html file association from the registry and launch the browser directly.

The QuickTime plugin should be fixed to a) not allow launching the default browser with arbitrary parameters and b) use the right API to launch the default browser (it's not really clear to me why it needs to do that anyways), but perhaps we can "fix" this particular case from our end.

A cross-platform testcase is available at:
http://people.mozilla.com/~gavin/bug/qt/test.mov
It alerts "Vulnerable" if privileged code was allowed to run.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Attachment: testcase

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Testcase returns "Server not found" page for me in a new tab on Minefield OSX, saying "Firefox can't find the server at www.-chrome%20javascript.com." so this might be Linux/Windows only.

Hooray for 3% of our user base!

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Yeah, it looks like Mac is not affected, and there's no QuickTime plugin for Mac (other plugins that play QuickTime files are unlikely to have the exact same flaw as the official QuickTime plugin on Windows), so this looks to be a Windows-only problem.

My testing was done on Windows with 7.2 and a trunk build, but this appears to affect any recent version of the QuickTime plugin (there's a comment on the blog about 2.0.0.6/QT5.6 not being vulnerable).

Comment 4

[logan]

I don't know about VLC or xine, but mplayer (all-20061022) doesn't seem to know what to do with this.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> and there's no QuickTime plugin for Mac

I meant Linux, of course.

Comment 6

[Daniel Veditz [:dveditz]]

note: they read the .html file association, and then ignore the actual registered command-line template they find (which includes "-osint") in favor of pulling out the executable and then simply appending the "qtnext" value without any of the other specified options.

QuickTime itself is where the bug lies, it does not have to be run as a plugin. If you've got a downloaded local file you get the same effect as long as Firefox is the registered .html (or .htm) handler.

QuickTime ought to be using ShellExecute() instead to get the default browser. If they are paranoid about launching a non-browser (as well they should be) they should vet the scheme against a whitelist of good schemes (http:/https:, maybe ftp:).

Mitigation: uninstall QuickTime. Disabling javascript does not help since chrome ignores that setting.

Protection on our end: drop support for the -chrome argument (adding an enabling pref for use by projects built on our platform, the intended use for -chrome). Regardless of the preceeding, use a whitelist of schemes with the -chrome argument, possibly including only chrome: and resource:.

Comment 7

[Giorgio Maone [:ma1]]

Would it be feasible to completely disable command line parsing, except for one single URL parameter maybe whitelisted on /^(https?|file|ftp):/, in the executable registered as the system-wide "default browser" or in similarly "public" roles, and provide a private command line interface enabled wrapper/alias (e.g. firefox-cli) for compatibility with legacy applications (if any), which would accept the whole story?

Comment 8

[Brendan Eich [:brendan]]

Cc'ing Eric in case he can help on the QT side. We have our own side to deal with so this is not a case where one fix on only one "side" suffices.

/be

Comment 9

[:Gavin Sharp [email: [e-mail]]]

I'm afraid that removing the -chrome argument entirely is going a bit too far... We're trying to mitigate an issue in another system level app here, so to avoid breaking things unnecessarily I think we should limit ourselves to preventing the specific type of attack that we're seeing. I can understand wanting to be extra sure that no variants are exposed once we've shipped a fix, but whitelisting the protocols that -chrome supports and thereby preventing command-line injection of code seems like it will fix the problem without impacting users of the current flag that rely on being able to point to code that's already on disk (resource:, chrome:, file:, etc). Just doing that would have also fixed bug 384384, right?

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> We have our own side to deal with so this is not a case where one fix on only
> one "side" suffices.

I'm don't see what on our side would need to be fixed, if QuickTime didn't have this flaw. We can reduce the odds of other broken apps being exploited to use us to execute code by treating any and all command line input as potentially malicious, sure, but I think that's also going too far. I think we should add the minimum number of restrictions on command line input that we need to protect our users, and without bugs in other apps that allow tunneling arbitrary parameters to Firefox, that minimum would be 0.

Comment 11

[Brendan Eich [:brendan]]

(In reply to comment #10)
> (In reply to comment #8)
> > We have our own side to deal with so this is not a case where one fix on only
> > one "side" suffices.
> 
> I'm don't see what on our side would need to be fixed, if QuickTime didn't have
> this flaw. We can reduce the odds of other broken apps being exploited to use
> us to execute code by treating any and all command line input as potentially
> malicious, sure, but I think that's also going too far. I think we should add
> the minimum number of restrictions on command line input that we need to
> protect our users, and without bugs in other apps that allow tunneling
> arbitrary parameters to Firefox, that minimum would be 0.

Meanwhile, back in reality, defense in depth is required, sometimes to a degree that compromises a single app's notion of command line utility.

/be

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Giorgio's suggestion in comment 7 sounds like a good one to me.  In some ways, it's like a DIY version of what bz and others have suggested that OS vendors should do: provide separate registration for "sandboxed" and "unsandboxed" handlers.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> Meanwhile, back in reality, defense in depth is required, sometimes to a degree
> that compromises a single app's notion of command line utility.

Defense in depth doesn't mean "rip out features indiscriminately"; you know that. There isn't only one solution to this problem, and you shouldn't dismiss my argument because I'm suggesting we should be careful before going too far.

Comment 14

[Giorgio Maone [:ma1]]

(In reply to comment #10)
> We can reduce the odds of other broken apps being exploited to use
> us to execute code by treating any and all command line input as potentially
> malicious, sure, but I think that's also going too far. I think we should add
> the minimum number of restrictions on command line input that we need to
> protect our users, and without bugs in other apps that allow tunneling
> arbitrary parameters to Firefox, that minimum would be 0.

I agree with trying not to break things -- hey, it's NoScript's mission
breaking stuff which Firefox was not brave enough to break ;)

So, what I was trying to say is that there are hooks registered at system level
or otherwise "public" interfaces to be used for inter-process communication
which already assume (more or less explicitly) that we're talking with "a
browser" which accepts only one parameter, i.e. an URL to open.
Exposing the whole set of command line options to these interfaces means
expanding the attack surface with no real advantage: those options won't be
used for any legitimate use, since they're not cross-browser.

So an alternate proposal to my rather radical "firefox" VS "firefox-cli" could
be "firefoxw" VS "firefox", much like "javaw" VS "java": a strict 1 argument
wrapper for public browser hooks, and the normal cli legacy-compatible
executable.

Comment 15

[Brendan Eich [:brendan]]

Gavin: where did I write that we should rip out -chrome? Where did I dismiss your argument for whitelisting?

What I objected to in comment 10 was utopian statements of the form "without bugs in other apps that allow tunneling arbitrary parameters to Firefox, that minimum would be 0." Sorry if I was unclear.

/be

Comment 16

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #15)
> Gavin: where did I write that we should rip out -chrome? Where did I dismiss
> your argument for whitelisting?

Apologies, my fault for misinterpreting your comment and reacting defensively.

> What I objected to in comment 10 was utopian statements of the form "without
> bugs in other apps that allow tunneling arbitrary parameters to Firefox, that
> minimum would be 0." Sorry if I was unclear.

I don't deny that it's utopian, but I do think it's true. You said "this is not a case where one fix on only one "side" suffices", and I just wanted to make it clear that were QuickTime able to somehow fix all deployed QuickTime plugins, that fix alone would suffice. Obviously that's not possible, so it wasn't a useful distinction to make, in retrospect.

Comment 20

[Daniel Veditz [:dveditz]]

Attachment: potential patch (1.8 branch)

Here's one potential patch for Firefox and Thunderbird (we can fix seamonkey the same way on trunk, but will require a different branch patch). This restricts -chrome to chrome: and resource: uris but does not kill the feature outright. People who want to do so can set the new prefs to false. Apps that install additional protocol schemes can add additional prefs if appropriate, and developers who insist on using file: can add that.

We should not support file: for general release because of UNC paths (and obviously not network protocols like http:)

Could have put the whitelisted schemes in a single string pref for compactness but then addons who need to alter it will fight over who sets it last.

This stops the published exploits but does not prevent QuickTime Media-link files from launching actual installed chrome resources. If any of those do bad stuff based on passed arguments then a hole remains. I'm mainly worried about addon chrome since our own chrome should already be avoiding this dangerous practice.

This also does not prevent QuickTime Media-links from calling other arbitrary command-line arguments. http://mxr.mozilla.org/mozilla/search?string=handleflag
We'll need to fix at least -install-global-extension/-theme somehow.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Comment 7 absolutely sounds like the way to go for me.  Whatever is registered as the default browser should have stringent vetting of input.  The "basic" binary need not do that, however.

Note that the attached patch, as it stands, will break at least the Txul test and the chrome mochitests.  The latter are trunk-only, but the former will send branch orange.

Comment 22

[Biju]

My camara make .mov file so I cant uninstall QuickTime.

So even though we cant stop this exploit being used when QuickTime running as standalone app.

To avoid being vulnerable when we surf using Firefox, or using Thunderbird 
we can disable "QuickTime Plug-in"
at menu Tools > Add-ons > Plugins


I also SeaMonkey for testing (even though Firefox is my default browser)

How do I disable "QuickTime Plug-in" in SeaMonkey?

Comment 23

[[e-mail]]

A possible alternative would be to do a URIChainHasFlags check for the URI_INHERITS_SECURITY_CONTEXT flag; this should block all unsafe schemes.
Alternatively, CheckLoadURI with DISALLOW_INHERIT_PRINCIPAL | ALLOW_CHROME ?

Comment 24

[Daniel Veditz [:dveditz]]

Attachment: 1.8 branch patch v2

turns out we don't want to block remote "-chrome http:" params, they don't run as privileged code and that feature forms the kernel for web-hosted desktop apps. Need to drop the pref approach and instead just kill the schemes that cause problems -- javascript: and data:

URIChainHasFlags doesn't exist on the 1.8 branch, so we can't use that approach. Would like to use it for the trunk patch though.

Could use checkLoadURI() and the DISALLOW_SCRIPT_OR_DATA flag, but for the branch checking schemes is simpler and avoids a few problems (no handy unprivileged principal, crashes if we end up blocking one I don't have time to debug right now).

The toolkit patch prevents the -install-global-extension/-install-global-theme parameters from being able to install files from remote UNC paths.

The other command-line options Firefox supports are not abusable in the same way. -jsconsole and -new-window could be annoying, for instances, but not dangerous.

-inspector if DOMI is installed looks OK, the URL loaded has no privileges, even javascript: and data:

The JSSH test server if installed could be dangerous, but that's by design and people shouldn't have that installed.

Chatzilla vets arguments to the -chat param. If irc: urls are dangerous then that's a problem from any web page and not just through this QuickTime problem.

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 280849 [details] [diff] [review]
1.8 branch patch v2

>+      // check URI scheme against whitelist

I'll fix that comment in the mail handler when I check in, obviously it's a blacklist now. I'll use the wording from the browser handler.

Comment 26

[Daniel Veditz [:dveditz]]

Attachment: trunk version

Comment 27

[[e-mail]]

Comment on attachment 280857 [details] [diff] [review]
trunk version

On the offchance that you need to change this patch for some reason...

>+const URI_INHERITS_SECURITY_CONTEXT = nsIHttpProtocolHandler
>+                                        .URI_INHERITS_SECURITY_CONTEXT;
Technically it's defined on nsIProtocolHandler ;-) I also wouldn't have minded it all on one line, it's only just over 80 chars and it's pretty obvious what the "missing" chars are :-)

>+        var netutil = Components.classes["@mozilla.org/network/util;1"]
>+                                .getService(nsINetUtil);
I would have named it netUtil, but whatever :-)

Comment 28

[[e-mail]]

At least with my simple test cases javascript: doesn't appear to be affected on the branch ("Permission denied to get property UnnamedClass.foo"), only on the trunk; data: is affected on both branch and trunk.

Comment 29

[Biju]

Attachment: test_popups.html (crashes QT 7.2 on windows -- beware!)

I and many others started using Mozilla to avoid popup and activex.
So please ensure above fix can also stop popups by 
testing using the attached test_popups.html.

test also from Seamonkey when firefox is the default browser.
and also other way arround.

I would a have wished "firefox" VS "firefox-cli" solution 
suggested in comment #14
And leave a power full command line option
>  firefox-cli.exe -chrome javascript:alert('hello from an ext pgm')
as feature for any application to use.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 280849 [details] [diff] [review]
1.8 branch patch v2

r- per comments on IRC (this scheme checking isn't sufficient).

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 280857 [details] [diff] [review]
trunk version

>Index: browser/components/nsBrowserContentHandler.js

>+        // only load URIs which do not inherit chrome privs
>         var features = "chrome,dialog=no,all" + this.getFeatures(cmdLine);
>-        openWindow(null, chromeParam, "_blank", features, "");
>+        var uri = resolveURIInternal(cmdLine, chromeParam);
>+        var netutil = Components.classes["@mozilla.org/network/util;1"]
>+                                .getService(nsINetUtil);
>+        if (!netutil.URIChainHasFlags(uri, URI_INHERITS_SECURITY_CONTEXT)) {
>+          openWindow(null, chromeParam, "_blank", features, "");

Maybe use uri.spec, to make sure the that you're actually using the result of the URI parsing (and therefore the URI that passed the security check)?

I only tested the /toolkit and /browser bits, r=me on those.

Comment 32

[Daniel Veditz [:dveditz]]

Attachment: 1.8 branch patch v3

Couldn't make checkLoadURI() work without crashing (null dereference trying to create an exception object on the "current window" since we don't have one). Had to simulate the nested URI support inline.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Why not use nsIJARURI like the security manager does instead of doing fragile string manipulation?

Comment 34

[Daniel Veditz [:dveditz]]

Bug 396196 filed to cover the launcher/wrapper program idea (comment 7). That approach would require changes to the installer and a lot more tendrils that I'm uncomfortable making in a rush to get this fix out for the branch.

Biju: as a branch firedrill we're not looking to make things perfect, just close off the worst trojan-installing aspects. We do expect Apple to fix QuickTime at some point, this is just to buy time until then.

Comment 35

[Daniel Veditz [:dveditz]]

Attachment: 1.8 branch patch v4 (use nsIJARURI)

Comment 36

[Daniel Veditz [:dveditz]]

Comment on attachment 280917 [details] [diff] [review]
1.8 branch patch v4 (use nsIJARURI)

approved for 1.8.1.7/1.8.1.8, a=dveditz

Comment 37

[:Gavin Sharp [email: [e-mail]]]

Leaving this list of URIs as sec-sensitive for now.

I tested before/after for the branch and trunk patches against the list of URIs at:
http://people.mozilla.com/~gavin/bug/qt/urilist.txt

using:

firefox.exe -chrome <uri>

Summary:

should be blocked:
jar:data:
jar:jar:data:
javascript:alert(Components.stack);
data:

shouldn't get chrome privs:
file:
http:

should still work (get chrome privs):
chrome:

Comment 38

[Daniel Veditz [:dveditz]]

Checked into MOZILLA_1_8_BRANCH and GECKO181_20070712_RELBRANCH for 1.8.1.8 and 1.8.1.7

Comment 39

[[e-mail]]

Attachment: XPFE patch

PFE startup is weird. Apparently the way to distinguish the chrome commandline handler is that it handles args but doesn't open the window with them.

Comment 40

[Daniel Veditz [:dveditz]]

According to http://docs.info.apple.com/article.html?artnum=305149 this problem shouldn't be happening regardless of the broken way in which the default browser is launched. qtnext is supposed to be limited to http: and https: urls (last advisory on the page).

Comment 41

[Carsten Book [:Tomcat]]

i used the Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/2007091417 Firefox/2.0.0.7 Firefox 2007 RC2 for some tests and http://www.gnucitizen.org/projects/0day-quicktime-pwns-firefox/ 

None of this testcases works for me in Firefox 2.0.0.7rc2. Only a second browser window is launched but no other application like calc or so.

Comment 42

[Daniel Veditz [:dveditz]]

The additional browser window is expected. If the -chrome argument is rejected then the browser will behave as if it's not there at all, generally opening a new window unless other arguments say to do something else.

Comment 43

[uamjet602]

Probably too late, but you could also include another binary or script specifically for this purpose (launching a browser from external sources), and for double measure make it check for the arguments that the registry specifies and bomb otherwise.

Comment 44

[Giorgio Maone [:ma1]]

(In reply to comment #43)
> Probably too late, but you could also include another binary or script
> specifically for this purpose (launching a browser from external sources), and
> for double measure make it check for the arguments that the registry specifies
> and bomb otherwise.

You probably mean Comment 7 and Comment 14, which Comment 34 morphed into Bug 396196.

Comment 45

[Boris Zbarsky [:bzbarsky]]

So is the "trunk version" patch still waiting on reviews?  Or does it just need approval to land?

Comment 46

[Dão Gottwald [:dao]]

Comment on attachment 280857 [details] [diff] [review]
trunk version

Already blocking -> approval not needed. mscott's review is pending.

Comment 47

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.7 after testsruns with the exploit testcases on http://www.gnucitizen.org/projects/0day-quicktime-pwns-firefox/

Tested the normal behavior when Firefox is loaded and also launching firefox with the testcases

-> adding verified keyword 

Comment 48

[Daniel Veditz [:dveditz]]

Comment on attachment 280995 [details] [diff] [review]
XPFE patch

sr=dveditz

a=dveditz to land this seamonkey only change on the branches.

Comment 49

[Daniel Veditz [:dveditz]]

Trunk version is just waiting for a non-busted tree to land. I keep missing the windows

Comment 50

[Daniel Veditz [:dveditz]]

(In reply to comment #46)
> Already blocking -> approval not needed.

According to the tree rules at the time ("threat level red") is was. Apparently the rules change day to day just to keep us on our toes.

Comment 51

[Daniel Veditz [:dveditz]]

Checking in browser/components/nsBrowserContentHandler.js;
/cvsroot/mozilla/browser/components/nsBrowserContentHandler.js,v  <--  nsBrowserContentHandler.js
new revision: 1.45; previous revision: 1.44
done
Checking in mail/components/nsMailDefaultHandler.js;
/cvsroot/mozilla/mail/components/nsMailDefaultHandler.js,v  <--  nsMailDefaultHandler.js
new revision: 1.9; previous revision: 1.8
done
Checking in suite/browser/nsBrowserContentHandler.js;
/cvsroot/mozilla/suite/browser/nsBrowserContentHandler.js,v  <--  nsBrowserContentHandler.js
new revision: 1.6; previous revision: 1.5
done
Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.255; previous revision: 1.254
done

Comment 52

[Carsten Book [:Tomcat]]

verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091804 Minefield/3.0a8pre and the exploit testcases - same results as for 1.8.1.7 see comment #47

- Changing Bug to verified

Comment 53

[Scott MacGregor]

Comment on attachment 280857 [details] [diff] [review]
trunk version

not sure if you still need this but it looks good to me Dan.

Comment 54

[Biju]

now attachment 280881 [details] test_popups.html   
is making firefox crash ir run CPU at near 100%

bug report
----------

BuildID: 2007091804
CrashTime: 1190164012
Email: [e-mail]
InstallTime: 1190163434
ProductName: Firefox
SecondsSinceLastCrash: 16
URL: https://bugzilla.mozilla.org/attachment.cgi?id=280881
UserID: b337f90c-beb0-4dbd-98ee-dca08d81381b
Vendor: Mozilla
Version: 3.0a8pre

This report also contains information about the state of the application when it crashed.

Comment 55

[Carsten Book [:Tomcat]]

(In reply to comment #54)
> now attachment 280881 [details] test_popups.html   
> is making firefox crash ir run CPU at near 100%
> 
thats bug 396228, but its not a regression of this bug/patch, has crashed also before the patch was checked in.

Comment 56

[Biju]

(In reply to comment #55)
> thats bug 396228, but its not a regression of this bug/patch,
> has crashed also before the patch was checked in.

Thanks for info

Comment 57

[Daniel Veditz [:dveditz]]

Biju's popup issue and crashing testcase moved to bug 396228. I've hidden the attachment here to avoid commingling the issues.

Comment 58

[pal-moz]

GP a8(M8) RC2 is released before official a8 ?

Comment 59

[Daniel Veditz [:dveditz]]

pal-moz: not entirely sure what you mean, but discussion not about fixing the bug in question does not belong in bugzilla. Please find our developer forums. Obviously our builds are available to testers in the "nightly" test directories before we actually release them, otherwise they would be released untested.

This bug is not fixed in the "M8" release today. The code-freeze for M8 was before this bug was filed. The bug is fixed in Firefox 2.0.0.7 and Firefox 3 nightlies.

Comment 60

[pal-moz]

(In reply to comment #59)
> This bug is not fixed in the "M8" release today. The code-freeze for M8 was
> before this bug was filed. The bug is fixed in Firefox 2.0.0.7 and Firefox 3
> nightlies.
> 

I know.
if M8 (the build including this bug) will be released, M8 will be a risky/dangerous build ?
so RC2 with this fix should be out/tested, then release as an official M8 build ?

Comment 61

[Daniel Veditz [:dveditz]]

M8 will be released with this flaw unfixed, M9 will come in a few weeks. Alpha builds are not intended for daily use, they are technology previews so people can play with the new features and do some compatibility testing. Anyone using the build on a daily or regular basis is a "tester", and testers should be using nightly builds (which will have the fix) rather than infrequent alpha builds.

Comment 62

[georgi - hopefully not receiving bugspam]

isn't running with user supplied http chrome risky?

Comment 63

[[e-mail]]

(In reply to comment #62)
>isn't running with user supplied http chrome risky?
Unlike data, http doesn't gain privileges from running as -chrome

Comment 64

[[e-mail]]

XPFE patch checked in to the branch.

Comment 65

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #64)
> XPFE patch checked in to the branch.

Seems to have broken Camino on the 1.8 branch -- the 1.8 branch Camino tinderboxes are unfortunately at http://tinderbox.mozilla.org/Camino/ .

Comment 66

[[e-mail]]

Sorry, the patch was missing a change to Makefile.in; I've fixed that now.

Comment 67

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.8 using the testcases and Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.8pre) Gecko/20070927 BonEcho/2.0.0.8pre ID:2007092704

Same results as for the 1.8.1.7 build (Comment #47)

-> Adding the 1.8.1.8 verified keyword

Comment 69

[Alexander Sack]

Comment on attachment 280917 [details] [diff] [review]
1.8 branch patch v4 (use nsIJARURI)

a=asac for 1.8.0.15

Comment 70

[Alexander Sack]

Comment on attachment 280995 [details] [diff] [review]
XPFE patch

a=asac for 1.8.0.15

Comment 71

[Christopher Aillon (sabbatical, not receiving bugmail)]

Committed attachments 280917 and 280995 to the 1.8.0 branch