Closed Bug 822072 Opened 12 years ago Closed 6 years ago

Ensure that packaged apps can only read signed data from the JAR package and restrict them from reading META-INF/*

Categories

(Core Graveyard :: DOM: Apps, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX
B2G C3 (12dec-1jan)

People

(Reporter: briansmith, Unassigned)

References

Details

Everything under META-INF/ in the app package is reserved for marketplace-specific metadata and for digital-signature-related metadata.

Because packaged apps and unpackaged apps are supposed to work as similarly as possible, we should not let packaged apps depend on the metadata that wouldn't be present in an unpackaged app.

More importantly, the META-INF/<whatever>.RSA file, which contains the certificate and the actual digital signature, can contain arbitrary unsigned data. Perhaps in the future we may be able to prevent such arbitrary unsigned data, but it is trickier than it appears. (The ability to store unsigned data in this file is needed in order to store signature-related data, like the certificate chain, that is needed to verify the signature. Because of the nasty complexities of X.509 certificate path building and verification, it is difficult to implement a restriction that prohibits unsigned data that isn't strictly necessary for the verification to be done.) Accordingly, it is important to prevent, at a minimum, reading the data in META-INF/<whatever>.RSA.
In bug 815523 comment 2 bsmith wrote:
> The JAR file format contains many nooks and crannies for unsigned content to
> be hidden (e.g. within the ZIP entry metadata, within ZIP "comments", within
> the unsigned parts of META-INF/*.RSA). So, either we'd have to rewrite the
> JAR to a known-clean state, or remote the JAR protocol so the parent process
> can limit the child process to just the entry data.

The implementation of bug 815523 results in the app being able to read any/all parts of the JAR file. That means we must strip out the parts of the JAR file that we don't want the app content process to be able to read. That is, instead of just doing a straight file copy, we need to use nsIJarWriter to write out a JAR that contains everything except META-INF/*.

This is actually really easy to do; I basically implemented it already in the "tamper" part of test_signed_jar.js.
Summary: Restrict packaged apps from reading from the META-INF part of the JAR → Ensure that packaged apps can only read signed data from the JAR package and restrict them from reading META-INF/*
> we need to use nsIJarWriter to write out a JAR that contains everything 
> except META-INF/*

I assume you're talking about doing this at install time?  That sounds fine.  We can change the code that's landing in bug 815523 to enforce that only the copy can be read.
Would we keep both the original and the copy?  Not very efficient from a disk space perspective.  It would be better to split the meta info and content into separate files w/o any bytes duplicated.
Agree we should fix this, but not a priority for 1.0.  App would have to be already trying to source a particular sensitive local file that is absent.
blocking-basecamp: ? → -
(In reply to Jason Duell (:jduell) from comment #3)
> Would we keep both the original and the copy?  Not very efficient from a
> disk space perspective.  It would be better to split the meta info and
> content into separate files w/o any bytes duplicated.

No, we would only keep one copy, and save the information we need from META-INF/ somewhere else.
Assignee: bsmith → nobody
Blocks: b2g-apps-v1-next
No longer blocks: privileged-apps
No longer blocks: b2g-apps-v1-next
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
blocking-basecamp: - → ---
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.