Closed Bug 1264093 Opened 8 years ago Closed 7 years ago

Create new bug entry form for client security bugs

Categories

(bugzilla.mozilla.org :: Custom Bug Entry Forms, enhancement, P1)

Product:
bugzilla.mozilla.org
Component:
Custom Bug Entry Forms
Version:
Production
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: amuntner, Assigned: dylan)

References

Details

Attachments

(1 file, 2 obsolete files)

PR
45 bytes, text/x-github-pull-request
dylan
: review+
Details | Review 
To prevent security bug submissions via email from being exposed due to STARTTLS downgrade attacks[1], Mozilla's bug bounty program should direct bug bounty hunters to submit issues through a web form on Bugzilla. This issue has been observed in the wild.[2]

SMTP server-to-server communication is out of our control. 

Proposing creating an equivalent of https://bugzilla.mozilla.org/form.web.bounty for client bugs, changing the bounty web page submission instructions. 


Requesting feedback from Chris Hoffman, Al Billings, Dan Veditz, Jeff Bryner

1. https://tools.ietf.org/html/rfc7457#section-2.2
2. https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
Flags: needinfo?(chofmann)
Flags: needinfo?(dveditz)
Flags: needinfo?(jbryner)
Flags: needinfo?(abillings)
Summary: Create new bug entry form for client bugs → Create new bug entry form for client security bugs
Ack, ideally subject should have minimal info since bug subject lines are searchable and display publicly.
Flags: needinfo?(jbryner)
sounds good to me.  we should probably 

1) harvest emails of all bugs filers that have bounty[?+-] and send them a notification of the new process once the form is up and running.  

2) update the FAQ pages with instructions on the process 

3) maybe the security@m.o auto responder should provide these instructions too.

I imagine we will still consider bounties for bugs received by mail but we should decide on how explicit we will be about that in program docs
Flags: needinfo?(chofmann)
(In reply to Jeff Bryner [:jeff]  (use NEEDINFO) from comment #1)
> Ack, ideally subject should have minimal info since bug subject lines are
> searchable and display publicly.

Where? From what I've seen security bugs are suppressed in buglists if you don't have rights to see them, and summaries are stripped from the Elastic Search data for security bugs. If we've got a problem with subjects in bug forms then we've got a bigger problem than just this one form; we shouldn't discourage good summaries in this form.

At the bottom of https://www.mozilla.org/en-US/security/client-bug-bounty/ we have 5 bullet points about creating a good hidden security bug and a final one saying to send the bug number or link to security@mozilla.org, and that's generally all we get. There's nothing for a STARTTLS attack to snarf. The savvier researchers might use our PGP key and send completely encrypted mail (ZDI does, for instance). The folks who send plaintext client security bug details to us via mail are generally not bounty seekers and are unlikely to find or use a form. For our existing regulars I worry that the form will encourage less detail than we tend to get from a direct bug submission. 

The form will set the bounty flag automatically (yay, bug 1257662 is fixed), and we could incorporate those 5 bullet points of what information we want into the form and simplify the instructions.
Flags: needinfo?(dveditz)
Ahh, my bad. Searching in a private profile I don't see anything by summary line so I must be just seeing things based on my perms. Are we sure that a 'muggle' user profile can't see summaries? Sometimes they are quite detailed and list params, etc.
Subject lines are definitely not displayed for confidential bugs.  No information is, aside from the bug ID.
I would prefer to force people to use a form instead of emailing us. I've wanted this for a long time due to the problems with email submissions.
Flags: needinfo?(abillings)
looks like there's agreement that a form is wanted.

can you please provide a list of the fields you want to collect, which fields are mandatory, and how those form fields map to bug fields.  note it's pretty common for the vast majority of fields to end up in the initial bug comment.
Component: Administration → Custom Bug Entry Forms
Flags: needinfo?(amuntner)
I took a crack at this, using the Web Bounty form as a model. Dan, Chris, Al, can you please review? Did I miss anything you'd like to see on the form?


Bug must be marked confidential

The following text must be included at the top of the page:

For more information, visit the <a href=https://www.mozilla.org/en-US/security/client-bug-bounty/>Mozilla Client Bug Bounty program</a> page


Field: Summary / Title
Please write a clear, descriptive title. 


Field: Comment
How was this issue discovered, include the steps, tools or other information that will help reproduce and diagnose the issue. Please follow Mozilla's 
<a href=https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines?redirectlocale=en-US&redirectslug=Bug_writing_guidelines>Bug Writing Guidelines</a>


Field: Attachment
Attach a "proof of concept" testcase, or point to explicit code that identifies the vulnerability or exploit. While not required, such a testcase will help us judge submissions more quickly and accurately.
If you have debug output or output from a tool demonstrating the issue, please include it in the bug. (If it is very long, please attach it to the bug as an attached file.)

Field: Description
(description for attachment)
Flags: needinfo?(amuntner)
i'm going to set needinfo as an indicator that we're not quite ready here yet; clear it once you've finalised the design with your team.

we'll also need to know which product/component to file the bugs into, and what security group to use to make them confidential.
Flags: needinfo?(amuntner)
Couple of questions and thoughts....

Are we going to have two forms (one for client and one for web) or ask the filer for rough categorization and and ask for different things based on the type of bug filed?

This might be a good opportunity to re-enforce some of the stuff in the FAQ about eligibility and expected contents in bugs including an indication that for web bugs the site is actually on the list of eligible sites, and for client bugs its not a simple DoS.   

It would be easy to over do the eligibility questions that are in form and make it annoying to frequent bug filers, but it would be a way to cut down on some of the noise in submissions. 

https://www.mozilla.org/en-US/security/bug-bounty/faq/

https://www.mozilla.org/en-US/security/web-bug-bounty/

Having submitter's take a crack at a rating based on the specific criteria we posted at https://wiki.mozilla.org/WebAppSec/Web_App_Severity_Ratings might also help to set expectations up front about what we are looking for and what we deem critical.
Chris,

There should be two forms. I'm going to be filing another bug to make changes to the existing web bug form.
Flags: needinfo?(amuntner)
(In reply to Adam Muntner [:adamm] (use NEEDINFO) from comment #11)
> Chris,
> 
> There should be two forms. I'm going to be filing another bug to make
> changes to the existing web bug form.

So are we still waiting or more information/approval for form #1? Is it going to be what is currently in comment 8? Or do we still need more details to proceed?

dkl
Flags: needinfo?(amuntner)
(In reply to David Lawrence [:dkl] from comment #12)

> So are we still waiting or more information/approval for form #1? Is it
> going to be what is currently in comment 8? Or do we still need more details
> to proceed?

I think it looks good and I think we should just move ahead. I feel empowered to make this decision so let's implement the client bounty form as soon as possible.
Flags: needinfo?(amuntner)
Assignee: nobody → dylan
Looks like this stalled out last year. Comment 8 is a good start but missing some information.

(In reply to Adam Muntner [:adamm] (use NEEDINFO) from comment #8)
> Bug must be marked confidential

Product:   Firefox
Component: Security

Group: Bug should be placed in the "core-security" group even though that's not the default for the Firefox product. If that's a problem then we can file it into Product: Core, Component: Security where that group is the default.

Flags: set the "sec-bounty" flag to '?'

> Field: Summary / Title
> Please write a clear, descriptive title. 

mark as a required field

> Field: Comment

mark as a required field

Al: anything else?
Flags: needinfo?(abillings)
Is there any way to give them displayed text to encourage them to attach any dumps or logs as file attachments?
Flags: needinfo?(abillings)
Given the customizations, is this something we'd want to build using the API, and host out of security.mozilla.org or similar domain? 

Also, what's the urgency on this. We have a GSoC candidate who will be working on bug entry forms this summer if their application is accepted?

Remember that we're trying to get out of the business of custom bug forms, but security bugs are something I think that could be an exception.
Severity: normal → enhancement
Flags: needinfo?(dylan)
Priority: -- → P3
We've been waiting a year and the web one has been up for quite a while now. I'd like to not wait another six months. Can't we just take the web security form, modify a few bits on it, and put this up?

No, I see no reason to use this in another domain unless the web security bounty form is in one.
(In reply to Emma Humphries ☕️ (she/her) [:emceeaich] (UTC-8) +needinfo me from comment #16)
> Given the customizations, is this something we'd want to build using the
> API, and host out of security.mozilla.org or similar domain? 
> 
> Also, what's the urgency on this. We have a GSoC candidate who will be
> working on bug entry forms this summer if their application is accepted?
> 
> Remember that we're trying to get out of the business of custom bug forms,
> but security bugs are something I think that could be an exception.

This type of form is not a problem, IMHO. The problem is non-software uses of forms (e.g. legal).
Security bugs are software bugs, and making it easier to get those sorted is useful. 

I'll try to get to this this week.
Flags: needinfo?(dylan)
Priority: P3 → P2
Any updates on this, Dylan?
Flags: needinfo?(dylan)
No, sorry it had dropped off my radar. I'm taking a look at what this would entail now.
Flags: needinfo?(dylan)
I have a rough draft of a Firefox :: Security form of this now that re-uses a few parts of bug modal (specifically, the summary line, the comment area (with preview). This method is drastically different than previous forms, and far more maintainable (and also, usefully, related to some work what my GSoC student will be working on in a few weeks).

Is there a particular reason this bug needs to be private?
Flags: needinfo?(abillings)
No, this bug doesn't need to be private.
Flags: needinfo?(abillings)
Group: mozilla-employee-confidential
Attached patch WIP.patch (obsolete) — — Splinter Review 
This is a work in progress patch, lest I lose it or forget about it.
Ok, a month later. Can we get this landed? :-)
Flags: needinfo?(dylan)
Comment on attachment 8868325 [details] [diff] [review]
WIP.patch

It's been largely superseded by sebastin's work, which I'll now rebase it on.
Attachment #8868325 - Attachment is obsolete: true
Flags: needinfo?(dylan)
Priority: P2 → P1
My attempts at this have been marred by issues of split focus -- by assigning this to Mary 
I suspect we'll get it done sooner.
Assignee: dylan → umohm12
Depends on: 1382085
Okay, so the big pain point here is setting the sec-bounty flag. For that we need the flag id for the flag 'sec-bounty'.
This should be a simple task, but it's complicated because there is no way to look that up (in the templates)
and nothing guarantee on that name being unique. I'm going to fix both problems.
Working on the form. Is there any introductory text you'd like included?
Flags: needinfo?(abillings)
Attached file github pull request (obsolete) — 

    
    

    
  
(In reply to Dylan Hardison [:dylan] (he/him) from comment #27)
> Okay, so the big pain point here is setting the sec-bounty flag.

How does the web-bounty-form handle that? Seems pretty reliable.

    
    

    
  
(In reply to Daniel Veditz [:dveditz] from comment #30)
> (In reply to Dylan Hardison [:dylan] (he/him) from comment #27)
> > Okay, so the big pain point here is setting the sec-bounty flag.
> 
> How does the web-bounty-form handle that? Seems pretty reliable.

it hard codes the flag type id (803), which means it can only be tested/worked on by
someone with a full bmo data dump (at least a metadata-only dump). 


It will also break if sec-bounty is ever forked
like 'review', 'sec-review' or dozens of other flags.

    
    

    
  
Due to some other complications, I'll take over this patch again.
Assignee: umohm12 → dylan

    
    

    
  
Drawing from the web form at https://bugzilla.mozilla.org/form.web.bounty

Summary / Title

A short description of the issue being reported including the version of Firefox and operating system used.

Comment

How was this issue discovered, include the steps, tools or other information that will help reproduce and diagnose the issue. A good primer on what to include can be found here (https://developer.mozilla.org/en-US/docs/Mozilla/QA).

Attachment

A file that can add context to the report, such as tool output or debug information showing symbols and error conditions.
Flags: needinfo?(abillings)

    
    

    
  
Ok, it has been another month so I'm pinging in this bug again. Any chance of this happening this quarter? (If the answer is "no," I'm cool with it but I'm checking in.)
Flags: needinfo?(dylan)

    
    

    
  

      
      
      
      

        Attached file
          
        PR
        — 
      

    


  
Finally got to this. 

I really wanted this to look "nice", but in the end that's going to have to happen after we do the global navigation redesign.

With that said, I made sure this at least works on a small screen.

        Attachment #8888129 -
        Attachment is obsolete: true
Flags: needinfo?(dylan)

        Attachment #8911986 -
        Flags: review?(glob)

    
  

        Attachment #8911986 -
        Flags: review?(glob) → review?(dkl)

    
    

    
  
Take it for a spin, and let me know what the whiteboard status field should be defaulting to, etc:
https://bugzilla-dev.allizom.org/form.firefox.security
Flags: needinfo?(abillings)

    
    

    
  
I've added some feedback, will defer to al for further feedback.

    
  
Depends on: 1403272

    
    

    
  
So one issue that Dan and I noted is that this has no reference or link to the bug bounty program. The title on it right now is "Firefox Security Form" and we should change that to "Client Bug Bounty Form" (the web one says "Web Bounty Form" on it as a title/header). 

I'd also like to add a link immediately under "Bug writing guidelines" (which is a link) to https://www.mozilla.org/en-US/security/client-bug-bounty/ with the text of "Client bug Bounty Program". I think that will head off some questions. 

The "Summary" line has the text of "A short description of the issue being reported including the version of Firefox and operating system used. " and I realized that this should just say "A short description of the issue being reported."

We should then adjust the "Description" line to say "How was this issue discovered, include the steps, tools, Firefox version, operating system version, or other information that will help reproduce and diagnose the issue. A good primer on what to include can be found here." (with "here" being the existing link).

When I submit a bug, it puts "[web-bounty-form]" in the whiteboard. We should change this to "[client-bounty-form]" since this is the client form, not the web one.
Flags: needinfo?(abillings)

    
    

    
  
Take a look at https://bugzilla-dev.allizom.org/form.client.bounty. It should have everything -- except I'm not sure I understood:

> I'd also like to add a link immediately under "Bug writing guidelines" (which is a link) to
> https://www.mozilla.org/en-US/security/client-bug-bounty/ with the text of "Client bug Bounty Program". I think that will head off some questions. 

because the page would then read:

Client Bug Bounty Form
Bug writing guidelines
Client bug Bounty Program

which would seem redundant.
Flags: needinfo?(abillings)

    
    

    
  
Well "form" and "program" are not redundant. You can make it "Details on Client Bounty Program" with a link to https://www.mozilla.org/en-US/security/client-bug-bounty/ 

"Bug writing guidelines" can be removed because it is in the "Description" area in the last sentence with a link.

So the form should say:

Client Bug Bounty Form

Details on Client Bounty Program

as the two items at the top.
Flags: needinfo?(abillings) → needinfo?(dylan)

    
    

    
  
Okay, I think I understand. The changes will appear in bugzilla-dev.allizom.org in the next 15 minutes or so.
Flags: needinfo?(dylan)

    
    

    
  
Comment on attachment 8911986 [details] [review]
PR

r=dkl

        Attachment #8911986 -
        Flags: review?(dkl) → review+

    
  
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: