Closed Bug 754837 Opened 8 years ago Closed 8 years ago

[Security Review] rest-symbol-server webapp


( :: Security Assurance: Review Request, task)

Not set


(Not tracked)



(Reporter: ted, Assigned: mgoodwin)




(Whiteboard: [completed secreview][fennec])

Who is/are the point of contact(s) for this review?
  Ted Mielczarek

Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
  The REST symbol server accepts Breakpad-format symbol uploads from users of the Android Symbol Server extension. This allows us to crowdsource symbols from system libraries on Android, which is important because of the wide variety of versions of system libraries. We originally had this service running on the a-team brasstacks dev machine, but that's no longer online, and I'd like to get this running on a production web server.

Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
  bug 668210 documents the original implementation of the extension.
  Extension source:
  Extension on AMO:

Does this request block another bug? If so, please indicate the bug number
  Not sure, may be a bug on hard-to-diagnose Android crash reports. (blassey?)

This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?
  We need to get this service back online to keep our Android crash reports useful.

To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list? If so, which goal?
  Supports Native Android Fennec release by keeping crash reports useful.

Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)
  Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?
    Only used by an extension that we ship via AMO.

    Are there any portions of the project that interact with 3rd party services?
    Will your application/service collect user data? If so, please describe 
      No, only information about stock system libraries is collected.
    If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):

    Desired Date of review (if known from and whom to invite.
      ASAP, probably only need me in attendance.
The webapp source is linked in the URL field. It's pretty trivial, it's just a REST web service. It allows clients to use HEAD to see if a specific symbol version exists, then PUT to upload a symbol file if it doesn't already exist. Symbol files are text format[1] and the app does some basic validation on them. Symbol files are stored on disk gzip compressed. The filename is determined from the path in the PUT request, which is restricted by the routing regex.

Whiteboard: [pending secreview][triage needed 2012.05.16]
Assigning to :mgoodwin but he is utilize right now so expect about 2 weeks before he can get to this.
Assignee: nobody → mgoodwin
Whiteboard: [pending secreview][triage needed 2012.05.16] → [pending secreview][fennec]
Whiteboard: [pending secreview][fennec] → [pending secreview][fennec][start date yyyy-mm-dd][target date yyyy-mm-dd]
09:04 <ted> it's implemented with, the whole thing is a single file: 
09:05 <ted> the other stuff in the repo is just tests, a base config file, and a checked-in copy of
09:23 <mgoodwin> ah, fantastic. thanks
Whiteboard: [pending secreview][fennec][start date yyyy-mm-dd][target date yyyy-mm-dd] → [pending secreview][fennec][start date 2012-06-11][target date 2012-06-15]
What date is this supposed to happen? (I think it's this week but I'm not 100% sure.)
(In reply to Ted Mielczarek [:ted] from comment #4)
> (I think it's this week but I'm not
> 100% sure.)

It is indeed.
14:11 <mgoodwin> how easy would it be for me to force a fennec client to talk to a local instance of the server?
14:11 <ted> really simple
14:11 <ted> there's a pref :)
14:11 <mgoodwin> heh, yeah
14:11 <mgoodwin> Ah, cool
14:12 <ted>
The only potential issue I can see with this is that people may take it upon themselves to send us fake symbol data. As we're preventing duplicates from being submitted, it wouldn't take long for an attacker to completely disrupt our collection plans.

It could be that we deem this an acceptible risk; if so, I'm happy to close this out.
What domain are we hoping to host this on?
I think it's an acceptable risk, in the same way that people can ostensibly submit fake crash reports or fake telemetry data or other things. The code does do some really basic validation of the contents, so it shouldn't be possible to submit arbitrary garbage data, they'd have to submit somewhat well-formed symbol files. That seems like more effort than anyone would bother with.

I don't really care about the domain, it's not user-visible.
Could we arrange for it to be hosted on its own subdomain? Reason I ask; it may be possible to craft files that look sufficiently like web content to get IE to execute script; I'd not like to see this being used to attack other applications.
That's fine with me. I can also make the webapp use content-disposition: attachment or whatever fiddly tricks are needed to make it so that GET requests don't display in a browser.
Brilliant, that would work nicely.

I'm happy with this. Closing review out.
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [pending secreview][fennec][start date 2012-06-11][target date 2012-06-15] → [completed secreview][fennec]
Blocks: 772939
You need to log in before you can comment on or make changes to this bug.