Closed Bug 190945 Opened 22 years ago Closed 13 years ago

allow users to upload a cert/gpg key to have the mails sent to them encrypted.

Categories

(bugzilla.mozilla.org :: General, enhancement)

Product:
bugzilla.mozilla.org
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hauser, Assigned: dkl)

References

Details

(Whiteboard: [bmo4.0-resolved])

Attachments

(1 file, 6 obsolete files)

Patvh v.7
7.47 KB, patch
mkanat
: review+
Details | Diff | Splinter Review 
might go under components "Administration", "E-Mail Notification", "User Accounts"

This makes particular sense for the usebuggroup security.
I'd put this one in Mail as that is the primary purpose and also the area that
will require the most modification.
Assignee: justdave → preed
Component: Bugzilla-General → Email Notifications
GPG should be PGP in summary.
Kick all my Bugzilla bugs back to the component default owner.
Assignee: preed → email-notifications
QA Contact: mattyt-bugzilla → default-qa
(In reply to comment #0)
> This makes particular sense for the usebuggroup security.
> 

some security sensitive bugs are expensive even on the public market.
network sniffing is relatively easy.
can sniff, have bugs.

the web part of bugzilla is encrypted, the mail part is not.

proposal:
don't send in email useful info about security sensitive bugs.
if gpg is implemented and there are enough keys, encrypt the info.
else
send mail:
--- 
bug XXX changed, visit https://.... to see changes
if you want sensitive spam, upload a gpg key
---

georgi probably thought of something like Bug 438572 as a fall-back in absence of the implementation of this bug here
dave,  think something like this is possible?
yes, if the bug is considered sensitive, i.e., not accessible by everybody, don't send the info via unencrypted email, just send url to check changes via an encrypted channel.

i believe even is gpg is not implemented, don't sending sensitive info via email is not much bugzilla perl code.
I remember hearing rumors that mkanat already had this at least partially implemented as part of the stuff he was doing to hack on the inbound email code (allowing users to upload a key that they could sign inbound mail with to be able to mail bugzilla).  Seems like this wouldn't be too much of a stretch to expand on that.
how about we just apply a "reduce the perimeter" fix to solve this problem with something like this in the processing of the e-mail content.

   if (bug_is_secrurty_sensitive)
      print "a security sensitive comment has been added to bug XXXXXXX, see the bug for more detail"

   else
      print the comment as we do now..


I think we could get by just fine with something like this and it definitely would reduce the amount of security sensitive comments floating around in clear text mail messages.

The bug titles and other fields might reveal some information that we wouldn't want floating around, but I think that is a level that we might be able to live with.

If we removed the bug title also we create some side effects like not providing enough information to figure out if I really need to go look at the new update, as would be the case with a lot of security meta bugs.  If I see a dependency update for a fuzzing meta bug now I know that's not a bug that I need to go look at...

would removing the comments from the mail and just providing a link to the comment work for others?
in some cases the subject of the email has a lot of info.

as in  "buffer overflow in FOO"
chris see the titles of Bug 414540 and Bug 425152 - the titles reveal quite of
the content of the bugs
searching shows there are a lot of interfaces to gpg from perl:

http://search.cpan.org/dist/Mail-GPG/
Mail::GPG   	 Handling of GnuPG encrypted / signed mails     	   	1.0.6
Mail::GPG::Result 	Mail::GPG decryption and verification results 

http://packages.debian.org/sid/libmail-gnupg-perl
GnuPG::Interface can process or create PGP signed or encrypted email
Considering that
1) S/MIME is a fully supported part of Thunderbird, SeaMonkey and even Outlook
Express (:-), and 
2) There is at least one CA recogized in Mozilla products that gives FREE 
certs to any/all mozilla users, and 
3) The PGP plugin for TBird (enigmail) prevents valid signatures on S/MIME
emails from being recognized (see bug 388865).

I think we should not adopt a method that depends on an unsupported and broken
add on.

I like Chirs's suggestion in comment 9.
I'm worried about the bug titles problem and revealing too much information there as georgi points out in comment 11.

I wonder if some extra logic like this in the mail message formating would help

   if (bug_is_security_sensitive && is_a_meta_bug )
    print "Summary: %Bug_Title% "
   else
      print "Summary: A Security bug # XXXXX needing your attention"

None of this makes if its not technically feasible to be running this extra logic over every mail message that bugzilla sends out.  justdave or someone more familiar with bugzilla should weight in on the feasibility of doing something like this.   

I think we should do something quickly though.  The problem and exposure to risk only gets worse with time.

This is a slippery slope to solve a problem that's never happened with Bugzilla, that I know of--the leak of information by somebody else getting access to your email account.

If somebody gets access to your email account, your account security is screwed anyway. If you're worried about somebody reading over your shoulder, they're just as likely to look at your web browser as they are to look at your email.
And I understand the problem of network sniffing, but nearly every MTA supports TLS nowadays. I know that I have my MTA send everything over TLS, if possible.
>network sniffing, but nearly every MTA supports
> TLS nowadays. I know that I have my MTA send everything over TLS, if possible.

yes, sniffing is the reason for this bug. 
>I know that I have my MTA send everything over TLS, if possible.

even if you use encryption to your isp's server, the mail travels in plaintext through half the world.

not all isps give encrypted channel to the mail server.
(In reply to comment #18)
> even if you use encryption to your isp's server, the mail travels in plaintext
> through half the world.

  I don't know, I have my mail server set to use TLS on relays, I'd imagine many servers do also (as I get a fair bit of inbound mail on a TLS connection as well).
whatever you use, b.m.o. sends the mail in plaintext, so a sniffer near b.m.o will sniff it, right?
opportunistic TLS is very easy to defeat - (as a MITM) just take out "STARTTLS" out of the ehlo response from the destination MTA and your own MTA will send the entire content in plaintext.
In case of mandatory TLS, the MITM is still a promising attack since the vast majority of those destination MTAs that do have a server-cert don't have a valid one (self-signed, expired, short key-lengths, domain-name mismatch, vendor sample/default key-pairs, ... you name it...  :( )
even if encryption at smtp level is perfect, this still leaves a lot of problems, some of which are:

1. the smtp chain of all recipients of a secret bug must be encrypted
2. the user must use encrypted pop3/imap/web mail
I talked to brendan a bit about this and I think he agrees, we should do some kind of scrubbing of message content as outlined in comment 9 and comment 14, at least as an experiment, and we should try and do it soon.   we could add some kind of encryption later if sanitization doesn't work.

dave,  how hard would these ideas about sanitization be to implement, and could we do something quickly?

(In reply to comment #23)
> I talked to brendan a bit about this and I think he agrees, we should do some
> kind of scrubbing of message content as outlined in comment 9 and comment 14

I use bugmail as an archive, and from my perspective not having local copies of comments (which means having to start a browser and load bugs to read bugmail) is pretty inconvenient.

It's not clear to me why we're suddenly considering these kinds of drastic measures to solve a problem that to my knowledge is purely theoretical.
I don't want to scrub bugzilla of comments. The topic I remember chofmann bringing up was emailing comments in the clear. Surely there's a better way to notify those with bugzilla access that they should go to b.m.o, log in if needed, and read the comment. Just a comment hyperlink would do, for me.

/be
(In reply to comment #25)
> The topic I remember chofmann bringing up was emailing comments in the clear.
> Surely there's a better way to notify those with bugzilla access that they
> should go to b.m.o, log in if needed, and read the comment. Just a comment
> hyperlink would do, for me.

Right, that's what I was reacting negatively to (inconvenience of having to load bugzilla to read bugmail, and loss of a local record of the comment).

I could deal with the inconvenience, to be sure, but I'm not sure that making these proposed changes would actually solve any problems. Sniffing mail in transit is possible, but hard, and even if someone manages to do it (or manages to break into your email account completely, even), not having direct access to the comments in email won't stop them - they can simply reset your Bugzilla password and gain access that way.

(Granted at least then it's easier to detect the intrusion, but even with that advantage I'm not sure the pros outweigh the cons. I understand my weighing of the cons is probably different than that of the majority of Bugzilla users.)
For what it's worth, I'm basically in agreement with Gavin on this. This is a fair bit of inconvenience to half-solve a problem which is only theoretical. That is, scrubbing won't really solve the problem (unless we reduce the email down to "Subject: [bug XXXX]" with the contents being a hyperlink, meaning that you'd have to GUESS what changed or read the bug History manually, meaning a load of Bugzilla for every notice from every security bug--imagine Bugzillas where every bug is in a group [which are somewhat common]!) and it's a totally theoretical problem.

I'm not denying that it, theoretically, *is* a problem. I'm just saying that we have hundreds of open bugs in Bugzilla which are practical problems and enormous amounts of work to do compared to the number of people we have to do it.

By the way, do most people even live on networks where their packets can be sniffed promiscuously, nowadays?
(In reply to comment #24)
> I use bugmail as an archive, and from my perspective not having local copies of
> comments (which means having to start a browser and load bugs to read bugmail)
> is pretty inconvenient.

Copies of encrypted mail can still be saved locally and archived.  We're just talking about protecting parts of security-sensitive bugmail in transit.  Non-security-sensitive bug mail would remain unchanged.

Packet sniffing is not a theoretical attack.  If it was, SSL would not be as widely deployed as it is.

Most people who have access to security-sensitive bugs are security aware and I don't think it's too much to ask those users to manage GPG or similar for a subset of their bug mail.

My 0.02.
(In reply to comment #28)
> Copies of encrypted mail can still be saved locally and archived.  We're just
> talking about protecting parts of security-sensitive bugmail in transit.

My objections weren't to encrypting bugmail using something like GPG (though I'm not sure the cost/benefit ratio is low enough there either). My objections were to the "strip comments from bugmail for security-sensitive bugs" proposal from comment 9 and 14.
bsterne: careful about malinvestment-prone analogies to SSL. As Gene Spafford famously remarked:

"Secure web servers are the equivalent of heavy armored cars. The problem is, they are being used to transfer rolls of coins and checks written in crayon by people on park benches to merchants doing business in cardboard boxes from beneath highway bridges. Further, the roads are subject to random detours, anyone with a screwdriver can control the traffic lights, and there are no police."

Session crypto is good, I like it. But does it really make e-commerce safe and secure? No, as phishers demonstrate.

Preventing attacks on security-sensitive bugs by encrypting bugmail comments could be costly and have not only little benefit, but opportunity costs and distraction effects.

/be
Don't get me wrong.  As I explained to Gavin in private e-mail I'm all for cost benefit analysis and coming up with a solution that is not a huge hit to productivity.

Here are the cost/benefit trade offs that I can see, and I think people would generally agree on given the discussion in this bug.

Exposure of bug comments to attackers that might lead to disclosure of security bugs and a long running series of zero day reports and exploits is one of the most catastrophic things that could happen to a large population of firefox users and to the mozilla project.   Even if network sniffing of the clear text e-mail transmissions is hard, work spent toward that effort his a high value target for someone that wants to work against the goals of the project and its user base.   High value target + hard to crack access to the information means that someone eventually might find the time and methods to exploit.

On the cost side I'm all for trying to find one or more solutions that preserve good productivity for as many, or all, the contributors working on these security bugs.   

The equation we have right now that looks like:

(X_security_bugs) x (y_e-mail_accounts) x ( a_variety_of_e-mail_systems_that_we_have_no_control_over) = wide_exposure_of_sensitive_info

widely expands the "footprint" of sensitive information no matter how you look at it.  I think this expansion is way beyond what might be needed to also ensure we maintain high levels of productivity. Maybe we need to maintain a special system for a few contributors like Gavin who build special archives of the security bug mail for increased productivity; but even if we had a few special cases we could reduce the exposure significantly over the situation we are in right now where we end up with the scary equation I listed above.  Auditing the trail of these special cases is reasonable as another protection measure.  Trying to audit the risk and information flow of the e-mail system we have right now is not very feasible.

Sound security design of just about all systems calls for reducing the secure perimeter as much as possible, and I think that we can work towards achieving something there.

I'm up for trying some experiments that work toward trying to find the right balance of reducing the secure perimeter of security bug mail and maintaining productivity and hopefully we will find the right balance and set of systems that works.

I think we should get going with some kind of e-mail sanitization system soon, even if its only opt in for those that want to help in reducing the footprint of security sensitive bug info, and then continue to refine and experiment with similar solutions and cryto as additional ways to reduce the risk.

i quite agree with Brandon Sterne   2008-06-23 18:21:52 PDT 
Comment #28

>Packet sniffing is not a theoretical attack.  If it was, SSL would not be as
>widely deployed as it is.

not sure i agree with brendan's comment:
>encrypting bugmail comments
>could be costly and have not only little benefit

so the benefit will be the user will have the email locally as in the old days.
re: costly
cost on the server side: there are available gpg interfaces for perl. i
*suspect* the additional coding won't be much
cost on the user side: the user must be clever enough to read encrypted mail
by clicking with the mouse and entering password. a "howto" with
screenshots covering popular mail agents probably will do for most users


afaict, there at least 2 possible solutions:

[1]. the easy one: see bug: <url-to-comment-or-whatever>

[2]. the functional one: 
if the user has uploaded key and can read encrypted mail, he gets the
encrypted bugspam
else fallback to [1]

I think email subjects are always plaintext (never encrypted).

A complete solution should change subjects from
  exploitable crash when clicking a bookmark named hello123
to
  new comment for security sensitive bug 444444

>I think email subjects are always plaintext (never encrypted).

according to my experience - yes.

>new comment for security sensitive bug 444444

this was discussed in comment #9 and #11
Regarding of inconvenience of not having an archive of bugzilla comments: what about adding such support to bugzilla itself? For example, it would be nice to have a page which shows all the comments for bugs a user is CC-ed on sorted in a mail order. Such tool can be more useful than the email interface and if users start to prefer it over email, it would also solve the problem of bugs that are marked as sensitive after filing.

In the mean time I strongly support the option of just stripping comments/subject from security bugs. Surely it causes extra hassles. But that would just add pressure to implement secure alternatives.
>Regarding of inconvenience of not having an archive of bugzilla comments: what
>about adding such support to bugzilla itself?

this is an interesting idea. it can probably be pushed further - integration of some web based email system with bugzilla, ideally giving export functions. though this is more difficult to implement i suppose.
Doesn't bugzilla already offer the features described in comment 35?
I guess the point is: Searching in bugzilla is slow, but people want gmail speed.

> The equation we have right now that looks like:
> 
> (X_security_bugs) x (Y_e-mail_accounts) x (Z e-mail_systems_that_we_have_no_control_over) =
> wide_exposure_of_sensitive_info

Useful equation (slightly tweaked by me). How do we reduce X, Y and Z?

X - fix bugs. We're doing that.

Y - send data to fewer people. Currently, anyone watching security@mozilla.org gets the first email on any security bug. We could stop doing that, or change those to "new bug filed - see XXXXXX" messages. We should probably also audit the list of people with security bug access.

Z - either encrypt the data, or don't send it. I'm working on a patch for this, based on the comments in this bug. Too early to say yet what functions it'll have :-) More later today.

Gerv

> Z - either encrypt the data, or don't send it. I'm working on a patch for this,
Note that one of NSS's test tools, built as part of NSS, is cmsutil, a program
that encodes and decodes the signed/encrypted parts of S/MIME emails.  It 
should be pretty easy to construct a shell script that encrypted outgoing email 
using cmsutil, I think.  
one other thought I had last night would be to sent only the first 2 or 3 words
of the bug title to help as a clue to the content of the bug..

In most title constructions we would catch the noun or the verb of the problem,
but not both, and reduce a bit risk of disclosure, but still provide some clues
to the content of the bug that just updated.  Using georgi's examples this is
what the subjects might look like.

Subject: [Bug XXXXXX] "buffer overflow in"
Subject: [Bug 414550] "stealing RDF and"
Subject: [Bug 425152] "heap overflow when"
Subject: [Bug 440865] "Content, Privacy and" 

and a few more examples

[Bug 306939] "[meta] Bugs found"
[Bug 344486] "[meta] XUL Element"

This relies on convention of the bug filers and maintainers to keep the titles
clean, but might be useful for keeping some level of productivity.

(In reply to comment #37)
> Doesn't bugzilla already offer the features described in comment 35?

Bugzilla does not allow to check *unread* comments for the bugs a user is CC-ed.

> I guess the point is: Searching in bugzilla is slow, but people want gmail
> speed.

That is also true.
> Y - send data to fewer people. Currently, anyone watching security@mozilla.org
> gets the first email on any security bug. We could stop doing that, or change
> those to "new bug filed - see XXXXXX" messages.

I don't think we can stop doing it all together.   We need some kind of alert system in place so the folks on security@m.o get notified when new security sensitive bugs enter the system.  Changing the message content might be ok.

>  We should probably also audit the list of people with security bug access.

yes, and we should also set up a regular schedule for follow up audits.
Attached patch Bugmail encryption patch v.1 (obsolete) — — Splinter Review 
This patch implements S/MIME bugmail encryption for security bugs (group 2). If no S/MIME certificate is available, it removes the diffs and the subject line from the email. (Although note that a lot of state information about the bug still exists in the headers. People may want to check those on bugmail they have to see if they think any other fields need to be blanked out.)

It requires the Perl module Crypt::SMIME, which itself requires libcrypto (OpenSSL; sorry Nelson :-)). This was chosen because it exists and works.

Key management is a slight hack, but in the name of simplicity, flexibility and robustness. Instead of trying to kludge in more user preferences for certificates etc., along with UI for uploading them, managing them etc., it uses attachments. The key is taken from the newest attachment which is:

- Uploaded by that user
- Non-obsolete
- Attached to a security-sensitive bug itself
- Has a description of "Public Key for Bugzilla Email"
- Contains "BEGIN CERTIFICATE"

Keys must be in PEM format (Base64-encoded X.509, .cer) - that's a requirement of the Perl module. (If my crypto terminology is off here in terms of certificate/key, I apologise.)

If the encryption fails, an error is appended to the bottom of the email in question. (We can't throw a Bugzilla error; it's probably not the fault of the person making the change.) This seemed better than just failing to send it, but others may have a different view.

(This is why it's important that the key is itself attached to a security-sensitive bug; otherwise someone could cause your secure email to be sent unencrypted by taking a newer attachment you had uploaded and renaming it to have the magic name. Encryption would then fail, and the message would be sent plaintext.)

The advantage of using attachments is that it makes the patch only 40 or 50 lines; any other mechanism would have been far more complicated to code.

PGP was not implemented because I couldn't find a Perl module which let me feed it the key rather than looking in the system keyring. If I can, that should be equally easy to add.

Feedback welcomed.

Gerv
Assignee: email-notifications → gerv
Status: NEW → ASSIGNED
Gerv, do you think there could be a single independent bug for collecting all recipient certs? I guess it would be convenient not having to attach one's S/Mime cert to every security sensitive bug separately.

What happens if certs expire and the user failed to attach a newer one? Will it still send encrypted email to everybody else?


Gerv, I'm quite happy with using OpenSSL here as long as the results 
conform to the standard and are fully interoperable with ThunderBird.
I expect that won't be any problem.

If I understand your proposal in comment 43 correctly, it sounds like
we'd be well served with a single security-sensitive bug named 
"Public Keys for Bugzilla Email" to which we can all attach our certs
as text/plain PEM encoded files.

Maybe we should also attach here some simple instructions on how to get 
a free email cert from StartCom or some other CA trusted by Thunderbird.


Kai: you definitely don't have to attach your key to each bug! As Nelson says, as a matter of practicality, we would probably end up just having a single bug as the "keys bug".

If the cert expires, then presumably the encryption would fail (although I haven't checked what the module does) and you'd end up back with plain text. It wouldn't affect anyone else's encrypted mail. Each mail is encrypted separately. As I said, we could stop sending email at all in this case, or just send a "bad key" mail.

There are instructions on how to get FREE FREE FREE certs (:-P) from various providers on MozillaZine here:
http://kb.mozillazine.org/Getting_an_SMIME_certificate

Gerv
will self signed certs work? i prefer not to bother with CAs.

>just having a single bug as the "keys bug"

if one can see someone else's key can one make it obsolete causing encryption dos? lol.
georgi: self-signed certs work, I think. At least, I'm testing with one.

Yes, you could cause an encryption DOS on another member of the security group
by fiddling with their key. But then, why would you want to? You have access to
the data anyway. (This is why it's important that the system checks that the
bug to which the key is attached is itself a security bug.)

Other Bugzilla hackers have pointed out that there are other potential Bugzilla
security problems, which they think are more important. Given that, can I get some confirmation from the group that it's worth continuing with this patch?

Gerv

>Bugzilla security problems

stealing bugzilla cookies is another bug but i see your point
Can I just remind everyone that this is a public bug? It was wisely pointed out to me that we shouldn't discuss specifics of other Bugzilla security bugs here. (Hence the private status of comment #48.)

Gerv
Attached patch Patch v.2 (obsolete) — — Splinter Review 
This version also supports PGP. 

We may need to evaluate the performance impact of this patch after we deploy it. Secure bugmail probably isn't a large percentage of bugmail, but crypto operations aren't necessarily cheap, and the OpenPGP module in particular has a lot of dependencies, which means quite a bit of code.

Gerv
Attachment #326505 - Attachment is obsolete: true
Install notes for Crypt::OpenPGP, in case they are useful for deployers. CPAN won't do all the job automatically - perhaps some of the dependency relationships are set up wrong. Anyway:

* Install Compress:Zlib from Debian packages, as CPAN doesn't work
* Install Crypt::Random
* Install Crypt::RSA
* Install Crypt::OpenPGP

Gerv

re comment 9
fwiw, at another bugzilla, we've made a mistake of configuring the system so that virtually all products have a mandatory group. this means that all bugs are "quasi" secret, and if bug_is_security_sensitive is defined as "is_in_group()" then bug tracking becomes useless.

we probably need to enhance groups to define whether a group really means secret or just access controls.

re comment 26
i proposed a long time ago that we could provide a local imap server which has a trusted path to bugzilla and force people to use that server to get secure bugs.

it's certainly annoying, but it might be better than losing all the content.
We should probably put the keys in LDAP at some later state, under another bug, but for now this patch does what this bug asks for.  We need a serious test suite for it, though, if we're going to rely it to protect people.

I agree, fwiw, that there are other areas of bugzilla security in which we would be better off investing, though I'm not sure that there is a true scarcity about which to reason.
will someone cc me on the most active bug discussing bugzilla security - a bug of mine is resolved as dup of bug 38862 but can't see it
Odd - you should have been auto-CCed when the bug was resolved as a dupe. I've CCed you now.

shaver: what sort of tests did you have in mind? 

But fundamentally, I see this as a bar-raising exercise (and I think it raises it a good distance, and it was already pretty high) rather than a "make it totally watertight in every circumstance" exercise. Yes, there might be security bugs in Bugzilla allowing people to replace the contents of an attachment which, assuming they knew which attachment to replace, would mean that people could switch keys on someone and then intercept their email... but this is getting really quite far-fetched IMO.

The latest version now fails with an error in the email rather than falling back to sending the data in plain text. So either the data will be sent correctly encrypted, unreadably (if the encryption goes haywire) or not sent at all.

Gerv

(In reply to comment #57)
> Odd - you should have been auto-CCed when the bug was resolved as a dupe. I've
> CCed you now.

Bugzilla no longer does that by default for bugs in groups... you have to explicitly select the option when the intermediate screen comes up.
Attached patch Patch v.3 (obsolete) — — Splinter Review 
Now never sends change data or comments unencrypted; better error reporting.

Gerv
Attachment #326657 - Attachment is obsolete: true
Attached patch Patch v.4 (obsolete) — — Splinter Review 
Version for review. I've tested this locally; I'm not sure what else we can do except start trying it out.

The irritating failure case would be if it started wiping out mails for non-security bugs. This could only happen if my SQL for determining what bugs are secure is wrong. So once that's carefully checked, then I think it's safe to proceed.

Gerv
Attachment #326861 - Attachment is obsolete: true
Attachment #327425 - Flags: review?(justdave)
in the light of the current dns circus shouldn't this patch be applied?
georgi: Unless I've misunderstood, the current DNS circus doesn't affect the importance or otherwise of applying this patch, because Bugzilla is accessed over SSL. Have I misunderstood the scope of the flaw?

Gerv
This isn't about accessing bugzilla, it's about the email bugzilla sends (in the clear).  Yeah, we need this in ASAP.  I'm about to jump on a plane for about 9 hours, I've snagged the patch to take with me and I'll get it reviewed on the plane.
Whiteboard: [wanted-bmo](asap)
Attached patch Patch v.5 (obsolete) — — Splinter Review 
Here is an un-bitrotted patch. I haven't re-tested it, but the code hasn't changed significantly around it as far as I can see. Still, I'll do some testing now.

For others testing: 
- install the patch
- Comment on a security bug
- Check the mail is gutted
- Upload a GPG key
- Comment on a security bug
- Check you can read the mail
- Upload an SMIME cert
- Comment on a security bug
- Check you can read the mail

Gerv
Attachment #327425 - Attachment is obsolete: true
Attachment #331341 - Flags: review?(mkanat)
Attachment #327425 - Flags: review?(justdave)
Target Milestone: --- → Bugzilla 4.0
Comment on attachment 331341 [details] [diff] [review]
Patch v.5

>+    # Core Security group is group 2 on b.m.o. We may want to add other 
>+    # groups; this variable is a comma-separated list.
>+    my $SECURITY_GROUPS = "2";

Don't put hardcoded stuff in patches which are supposed to land upstream. If you want something specific to b.m.o, file a bug in the appropriate product, i.e. not here.


>+      # Look for a public key with which to encrypt.
>+      # Key is the most recent attachment which is:
>+      # - uploaded by the user 
>+      # - attached to a secure bug 
>+      # - non-obsolete 
>+      # - described as "Public Key for Bugzilla Email".

Couldn't be uglier, IMO. Your key should be invisible to other users and be uploaded from userprefs.cgi in the "User Account" section. From a DB schema point of view, this means adding another column to the profiles table with the public key in it. This also lets you manage your own public key much more easily.


>+      # This module has a _lot_ of dependencies.
>+      use Crypt::OpenPGP;

Your comment is exactly the reason why this module should not be mandatory on all Bugzilla installations. If the maintainer doesn't want to install it, don't prevent Bugzilla to work correctly. This module should be optional, be referenced by checksetup.pl and the code should correctly check if this module is available or not.

About comments being dropped from security bugmails, I'm totally against this. This is critical enough to provide a user pref where the user can decide what to do when receiving bugmail from a security bug: either display the comment in it or put a link pointing to the added comment. Of course, this user pref should only be displayed if all Perl modules above are installed; else it doesn't make sense to offer this pref to the user.


I don't mind if this makes the patch bigger. Do it cleanly rather than in a quick and ugly way. (or do it quickly and in an ugly way, but in another bug being in another product...)
Attachment #331341 - Flags: review-
(In reply to comment #65)
> >+    # Core Security group is group 2 on b.m.o. We may want to add other 
> >+    # groups; this variable is a comma-separated list.
> >+    my $SECURITY_GROUPS = "2";

Oh, and timeless's comment 54 is perfectly valid. You may have to add a checkbox in editgroups.cgi to decide which groups need encryption and which ones do not. But this may be kept for a separate bug, assuming we want it.
See buglist.cgi: it distinguishes secure_mode between implied and manual. Maybe this can be made of use here. To me, it'd make sense if bugmail needed encryption iff the bug's secure_mode is manual. This is an intuitive way to get rid of quasi-secretness.
(In reply to comment #65)
> (From update of attachment 331341 [details] [diff] [review])
> >+    # Core Security group is group 2 on b.m.o. We may want to add other 
> >+    # groups; this variable is a comma-separated list.
> >+    my $SECURITY_GROUPS = "2";
> 
> Don't put hardcoded stuff in patches which are supposed to land upstream.

This patch is not supposed to land upstream.

> Couldn't be uglier, IMO.

This patch is not supposed to land upstream.

> Your key should be invisible to other users and be
> uploaded from userprefs.cgi in the "User Account" section. 

No doubt, if this patch were to land upstream, that would be what I'd do. But it's not.

> Your comment is exactly the reason why this module should not be mandatory on
> all Bugzilla installations. 

Which it won't be, because this patch is not to land upstream.

> About comments being dropped from security bugmails, I'm totally against this.

Tough, sorry. The current Internet environment, particularly the DNS problems, means that we have to do it for b.m.o. At least, georgi thinks so, I think so and shaver thinks so. Other Bugzillas can choose what they want to do, because this patch is not to land upstream. :-)

If you think it's in the wrong product or component, feel free to move it.

wurblzap: interesting idea, if something implementing this feature were ever to land upstream :-)

Gerv
Attached patch Patch v.6 (obsolete) — — Splinter Review 
Fixes a small bug, removes a few warnings. Now tested again with SMIME - works fine. Will need to download Enigmail to test with GPG. But I can't see any reason it would have broken.

Gerv
Attachment #331341 - Attachment is obsolete: true
Attachment #331393 - Flags: review?(mkanat)
Attachment #331341 - Flags: review?(mkanat)
(In reply to comment #68)
> This patch is not supposed to land upstream.

So we've effectively hijacked a bug that was meant for upstream and used it for stuff that isn't.

However, I'd really like to see this upstream, in a clean way, with all the stuff LpSolit and Wurblzap mentioned.  So how about we do it this way...  we get this up to the point where it does what it needs to do for bmo, as quick as we can, since the current DNS environment makes this kind of an emergency, get that committed on bmo's bzr branch, and then continue working on this on this bug using the bmo patch as a base for it and add in the other parts to make it useful upstream, but not in quite so much of a rush, so we do it right.

(In reply to comment #65)
> >+      # Look for a public key with which to encrypt.
> >+      # Key is the most recent attachment which is:
> >+      # - uploaded by the user 
> >+      # - attached to a secure bug 
> >+      # - non-obsolete 
> >+      # - described as "Public Key for Bugzilla Email".
> 
> Couldn't be uglier, IMO. Your key should be invisible to other users and be
> uploaded from userprefs.cgi in the "User Account" section. From a DB schema
> point of view, this means adding another column to the profiles table with the
> public key in it. This also lets you manage your own public key much more
> easily.

I would vote for this even for bmo's version if for nothing else than CPU usage on the Bugzilla servers.  Doing that attachment selection every time we process a mail recipient is going to use a whole lot of disk I/O and CPU on the database server, and probably slow down the mail even worse than it's already going to by encrypting it.  If the key is in the profiles table it can even be loaded as part of the User object and then it's already there when we want it.

Something else to keep in mind... b.m.o is currently running Bugzilla 3.0.4+. So the initial bmo-specific patch needs to apply to that.  You can check out the existing bmo code (which includes any other local patches we've applied) from

bzr co http://dm-bugstage01.mozilla.org/bmo/3.0 bmo-3.0

>it's about the email bugzilla sends (in the clear)

yes, that is what i meant.

in addition, the current multivendor dns patch seems of questionable quality:

http://lists.grok.org.uk/pipermail/full-disclosure/2008-July/063130.html

Here's the picture:

                     normal         colliding      sniffing
                     blind attack   blind attack   attack
                     ------------   ------------   --------
   nothing           1              1              1
   ID (BIND)         65536          256            1
   ID+port (djbdns)  4227727360     65020          1


the sniffing part is obvious.

my network skills are lame though i suppose in this context ``colliding'' refers to the birthday paradox.




I'm moving this bug to the bmo component. If somebody also wants a similar feature upstream, we should file a separate bug for it.
Component: Email Notifications → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
Target Milestone: Bugzilla 4.0 → ---
Version: unspecified → other
I have plans to review this patch on Tuesday, or possibly today (Monday) if I get to it.
Comment on attachment 331393 [details] [diff] [review]
Patch v.6

  Before I do this review, I hope that everybody is aware that this doesn't protect Whine mail.

>=== modified file 'Bugzilla/BugMail.pm'
>+    # Core Security group is group 2 on b.m.o. We may want to add other 
>+    # groups; this variable is a comma-separated list.
>+    # XXX Group 15 is GRM testing; remove it and this comment.
>+    my $SECURITY_GROUPS = "2, 15";

  It would be best, for the admins, to put this into a parameter, as a multi-select on groups.

>+    # Using raw SQL because we don't have a bug object.

  Why not just create a Bug object? You could do this check much higher up in the code, once per bug, then it would be OK.

>+    my $issecure = Bugzilla->dbh->selectcol_arrayref(
>+       "SELECT group_id FROM bug_group_map 
>+         WHERE bug_id = ? AND group_id IN ($SECURITY_GROUPS)", undef, $id);

  You could just call COUNT(*) there and do selectrow_array.

>+    if ($issecure->[0]) {
>+      # In at least one security group. Move the summary into the body.
>+      $diffs = "Summary: " . $values{'short_desc'} . "\n" . $diffs;

  Doing that here will put it *below* the comment.

>+      # Look for a public key with which to encrypt.
>+      # Key is the most recent attachment which is:
>+      # - uploaded by the user 
>+      # - attached to a secure bug 
>+      # - non-obsolete 
>+      # - described as "Public Key for Bugzilla Email".
>+      # Attachment MIME type is irrelevant.

  I honestly think you'd actually have an *easier* time, code-wise, adding a <input type="file"> or a <textarea> to userprefs.cgi. It would also be guaranteed to perform well, instead of searching attachment descriptions, which may or may not perform well.

>+      # S/MIME Keys must be in PEM format (Base64-encoded X.509, .cer)
>+      # PGP keys can be either binary or ASCII-armoured.
>+      $key = Bugzilla->dbh->selectcol_arrayref(
>+        "SELECT thedata FROM attachments, attach_data, bug_group_map WHERE 

  Nit: It would be nice if this were formatted according to the guidelines in the Developer's Guide for SQL.

>+          attachments.description = 'Public Key for Bugzilla Email' AND 

  The other problem with that is that it's too error prone. Any misspelling or adding of spaces and suddenly it won't work, and the user will be mystified.

>+      $key = $key->[0] ? $key->[0] : "";

  If there are no results, $key->[0] will die.

>+      # This module has a _lot_ of dependencies. The advantage of using it is
>+      # that you can feed it the key from data you have, rather than needing
>+      # the key to be on a system keyring.
>+      use Crypt::OpenPGP;

  All "use" statements must be at the top of the file. They execute at compile-time, so it's pointless to put them lower in the code.

>+      my $pubring = new Crypt::OpenPGP::KeyRing(Data => $key);
>+      my $pgp = Crypt::OpenPGP->new(PubRing => $pubring);

  Be consistent--either use indirect object syntax ("new Class") or method-call syntax ("Class->new"). Since the rest of Bugzilla currently uses the indirect object syntax, I'd recommend that.

>+      my $ciphertext = $pgp->encrypt(Data       => $diffs,

  I don't think this will actually be enough--you need to encrypt the whole email that's returned to you from the template, I'm pretty sure. I suspect many email clients won't even understand that this is an encrypted message unless the entire body is encrypted.

  There are CPAN modules that can do this, I've used them in the past.

>+                                     Recipients => "@", # 'everyone' :-)

  Everyone? Could you explain that a bit more?

>+      else {
>+        # Error in $pgp->errstr();
>+        $diffs = "\n\n\n*** ERROR: PGP ENCRYPTION FAILED. ***";

  Are you going to include $pgp->errstr()? Otherwise we won't have any idea what happened.

>@@ -680,6 +748,31 @@
>+    if ($key =~ /BEGIN CERTIFICATE/) {
>+      use Crypt::SMIME;

  Same comment here about the "use".

>+      my $smime = Crypt::SMIME->new();

  And the new().

>+        # Can't throw a Bugzilla UI error - it may well not be the fault of 
>+        # the person making the change. So delete the entire message body 
>+        # and append an error.
>+        $msg =~ s/(show_bug\.cgi\?id=\d+).*$/$1/s;

  That relies a lot on the current format of the mail.

>+        $msg .= "\n\n\n*** ERROR: S/MIME ENCRYPTION FAILED. ***";

  And also here--why did it fail?

>=== modified file 'Bugzilla/User.pm'
>+# This returns a hash, indexed by group name.
> sub groups {

  We can add that comment upstream, if we need it.


  As far as all the code-formatting comments go that I made, I'm aware that this isn't going upstream, but whatever code you check in here, *I* have to maintain, so that matters to me.
Attachment #331393 - Flags: review?(mkanat) → review-
Max,

Thanks for the review. New patch coming up. Anything I've not commented on, I've done.

(In reply to comment #74)
>   Before I do this review, I hope that everybody is aware that this doesn't
> protect Whine mail.

Whine mail contains bug subjects but not comments or attachment details, right?

How widely used is whine mail for security bugs on b.m.o.?

> >=== modified file 'Bugzilla/BugMail.pm'
> >+    # Core Security group is group 2 on b.m.o. We may want to add other 
> >+    # groups; this variable is a comma-separated list.
> >+    # XXX Group 15 is GRM testing; remove it and this comment.
> >+    my $SECURITY_GROUPS = "2, 15";
> 
>   It would be best, for the admins, to put this into a parameter, as a
> multi-select on groups.

Doing this falls into the same basket as the user pref - see below.

> >+    # Using raw SQL because we don't have a bug object.
> 
> Why not just create a Bug object? You could do this check much higher up in
> the code, once per bug, then it would be OK.

There's an existing bug on changing the mail sending process to use a Bug object. I didn't create one because I was concerned about the performance impact. If you don't think that's a problem, then I can.

I have moved the code further up, though, so it only calls it once per bug.

> >+    if ($issecure->[0]) {
> >+      # In at least one security group. Move the summary into the body.
> >+      $diffs = "Summary: " . $values{'short_desc'} . "\n" . $diffs;
> 
>   Doing that here will put it *below* the comment.

I've tested the patch, and I promise you it doesn't :-)

>   I honestly think you'd actually have an *easier* time, code-wise, adding a
> <input type="file"> or a <textarea> to userprefs.cgi. It would also be
> guaranteed to perform well, instead of searching attachment descriptions, which
> may or may not perform well.

I agree this is the right thing for a proper patch, but we are under time pressure here. People are getting their DNS hijacked on the web _right_now_. I don't want to have to write more code because it then has to be tested and debugged. What we have works. I am currently at the Summit and supposed to be doing Summity things; when I return, I'm on holiday for two and a half weeks. If someone else is going to step up to add these things, great, but I really don't think I have time between now and then.

As for the performance, attachments.submitter_id has an index, so it is only searching the titles of all the attachments the person has added. If there's still a problem, can we add an index on "description"?

> >+          attachments.description = 'Public Key for Bugzilla Email' AND 
> 
>   The other problem with that is that it's too error prone. Any misspelling or
> adding of spaces and suddenly it won't work, and the user will be mystified.

I've changed the description to "MAILKEY". Note also that I'll be filing the bug to hold all the keys, so I'll see the attachments being attached, and if anyone manages to misspell MAILKEY, I can fix it.

> >+      my $ciphertext = $pgp->encrypt(Data       => $diffs,
> 
>   I don't think this will actually be enough--you need to encrypt the whole
> email that's returned to you from the template, I'm pretty sure. I suspect many
> email clients won't even understand that this is an encrypted message unless
> the entire body is encrypted.

Thunderbird manages fine. The reason PGP blocks have those headers and footers on them is so they can be extracted from the middle of emails. (Imagine forwarded email, for example.) Do you know of a mail client where this doesn't work?

>   There are CPAN modules that can do this, I've used them in the past.

The module I am using is the only one I could find which does not require system PGP and for all the keys to be part of an on-disk keyring file. If you have an alternative module to suggest which also has these properties, I'm all ears, because this one has a lot of dependencies :-)

> >+        # Can't throw a Bugzilla UI error - it may well not be the fault of 
> >+        # the person making the change. So delete the entire message body 
> >+        # and append an error.
> >+        $msg =~ s/(show_bug\.cgi\?id=\d+).*$/$1/s;
> 
>   That relies a lot on the current format of the mail.

Somewhat, but we have control over that, so that's OK. A long-term patch may well take a different approach.

>   As far as all the code-formatting comments go that I made, I'm aware that
> this isn't going upstream, but whatever code you check in here, *I* have to
> maintain, so that matters to me.

Of course. I've made all the code-formatting changes you requested.

Gerv
Attached patch Patvh v.7 — — Splinter Review 

        Attachment #331393 -
        Attachment is obsolete: true

        Attachment #331764 -
        Flags: review?(mkanat)

    
    

    
  
(In reply to comment #75)
> I agree this is the right thing for a proper patch, but we are under time
> pressure here. People are getting their DNS hijacked on the web _right_now_. I
> don't want to have to write more code because it then has to be tested and
> debugged. What we have works.

The code to add is so trivial and straightforward to write that not doing it really means that you didn't try to spend 5 mimutes looking at it.

    
    

    
  
I am currently contending with launching a mail data initiative, gathering contributor forms, Vorbis and Theora-related issues, a Bugzilla reorg, a rockslide and resulting 8-hour coach journey combined with 5 hour wait and 9 hour flight, the need to prepare Bible studies for next week, plus about five thousand things that I need to talk about with various Summit attendees. Can we please, just this once, accept code that works until we can replace it with code that is both beautifully architected and works?

I'll even write migration code from attachments to user prefs. Just not _now_.

Gerv


    
    

    
  
Comment on attachment 331764 [details] [diff] [review]
Patvh v.7

From a code perspective, this is fine as a local hack for bmo.

To go upstream we need:

1) Proper PGP/MIME encryption of the whole message for PGP.

2) A userprefs column instead of an attachment.

3) Possibly some abstraction of stuff out into subroutines instead of being inline.

        Attachment #331764 -
        Flags: review?(mkanat) → review+

    
    

    
  
committed to the bmo 3.0.x branch:

Committing to: /var/www/html/everythingsolved.com/bzr/mozilla/3.0/
modified Bugzilla/BugMail.pm
Committed revision 5178.

I'm currently porting it forward to the 3.1.x branch.

Now we just have to wait for justdave/somebody to update bmo itself. Note that you might want to sync this up with the 3.0.5 update (particularly since my 3.0 branch already has most of the 3.0.5 changes in it).

    
    

    
  
Actually, the 3.0 version wasn't even compiling (I thought you had tested it, gerv?). I fixed it:

Committing to: /var/www/html/everythingsolved.com/bzr/mozilla/3.0/
modified Bugzilla/BugMail.pm
Committed revision 5179.

    
    

    
  
Okay, this exists also in the 3.1 branch now:

Committing to: /var/www/html/everythingsolved.com/bzr/mozilla/3.2/
modified Bugzilla/BugMail.pm                                                   
Committed revision 6122.

And that works and contains the fix and all (tested and all).

    
    

    
  
fwiw, whines are mostly exposed to people in the security group, so while i'm not sure if they're used for that purpose, it was expected that they would be.

i don't personally use whines for security things for a couple of reasons, one of which is the fact that i don't have a secure mail path (i.e. this bug), and as such, my global watcher isn't configured to receive secure bug mail at all. - This doesn't mean that I want secure bug mail to be mangled before it would be delivered to me if i were to change my preferences. it's merely a current state because I'm waiting for this and a couple of other things.

I don't have energy to try to figure out what the current patch is, so i'm assuming it's attachment 331764 [details] [diff] [review];
+    my $SECURITY_GROUPS = "2, 15";

i'd rather:

my $SECURITY_GROUPS = qw(
2
15
);

that'd make diffing easier. also note that there are 3 security groups today.

+    if ($issecure) {
+      # In at least one security group. Move the summary into the body.

indentation in file is 4 space

+      $diffs = "Summary: " . $values{'short_desc'} . "\n" . $diffs;
+      $values{'short_desc'} = "Bug has changed (security-sensitive)";
+      

I like comment 40's suggestion and would request that it be implemented. the current changes make hypothetical browsing w/ gmail essentially useless.

note that the patch has trailing whitespace on lines...

+    # S/MIME works on the entire message, so we do the encryption now it's
+    # been constructed.

now that it has been

If you insist on using the attachments table, I think it'd be nice if the encryption daemon would poke the bug containing the attachment as follows:
1. mark the attachment as obsolete with comment
2. comment: [PGP|SMIME] key failed

the datestamp can be the normal one from making a change to a bug/attachment. this would mean that at first failure keys would be dropped and the people watching that bug could see it and do something (like make a phone call).

If a key actually does work, someone can reenable it my clearing obsolete.

    
    

    
  
(In reply to comment #83)
> also note that there are 3 security groups today.

Five security groups, actually.

    
    

    
  
(In reply to comment #84)
> Five security groups, actually.

Because you plan to include all five groups? This would break emails sent to security@ when bugs are filed with the security bit set. I doubt these mailing-lists have a PGP cert, and so the usual content of these emails wouldn't be sent.

    
    

    
  
Is there a scheduled time for upgrading, to get this in place?

    
    

    
  
Mike: bug 450310 covers the next upgrade. Justdave said today that "It's probably happening this coming week."

Gerv




    
    

    
  
(In reply to comment #86)
> Is there a scheduled time for upgrading, to get this in place?

I'm pretty sure we decided not go with this patch for now. At least that's my understanding of it...

    
    

    
  
(In reply to comment #88)
> I'm pretty sure we decided not go with this patch for now. At least that's my
> understanding of it...

  No, as far as I know we're still using it. It's in my repo, at the least.

    
    

    
  
(In reply to comment #89)
> (In reply to comment #88)
> > I'm pretty sure we decided not go with this patch for now. At least that's my
> > understanding of it...
> 
>   No, as far as I know we're still using it. It's in my repo, at the least.

Pretty sure justdave backed it out of our repo, but I could be wrong. I personally don't like the hack as it stands, and I think that if we're going to take it, it should be done in better form, as mentioned in earlier bug comments.

    
    

    
  
(In reply to comment #90)
> Pretty sure justdave backed it out of our repo, but I could be wrong. I
> personally don't like the hack as it stands, and I think that if we're going to
> take it, it should be done in better form, as mentioned in earlier bug
> comments.

  Then you'll have to do it, probably today, because neither justdave, nor gerv, nor I have time in our schedules.

    
    

    
  
(In reply to comment #90)
> Pretty sure justdave backed it out of our repo, but I could be wrong. I
> personally don't like the hack as it stands, and I think that if we're going
> to take it, it should be done in better form, as mentioned in earlier bug
> comments.

I did back it out of staging, but only because of missing prerequisites, and apache wouldn't start with it there.  I do agree that this patch feels like a hack, but nobody has any time to improve on it right now, and it's still much better than nothing.  I'd be quite happy to deploy a better solution whenever it's ready without waiting for another full upgrade, too.

    
    

    
  
(In reply to comment #91)
>   Then you'll have to do it, probably today, because neither justdave, nor
> gerv, nor I have time in our schedules.

Shouldn't take more than an hour or two to write both the UI and the backend code to upload the certificate and to update gerv's patch to use it. I may update his patch myself if I'm in a good mood. :)

    
    

    
  
Another problem with this approach is that all non-security-group members can't add their GPG keys (since the bug that has all the keys is security group only), so when people report security bugs who aren't in the security group, they are effectively screwed.

    
    

    
  
They are not "effectively screwed" - any screwage is entirely ineffectual, because they can visit the bug to see the update, just like anyone else without a key. And, because the keys don't have to be attached to a _special_ security bug, if they are fed up of visiting the bug then they can attach their key to that bug itself, whereupon it will work for those emails and any others they might get in the future.

Gerv


    
    

    
  
(In reply to comment #28)
> Copies of encrypted mail can still be saved locally and archived.

But not actually searched for those of us who use Gmail, fwiw. But that's an aside. Moving on...

> Packet sniffing is not a theoretical attack.  If it was, SSL would not be as
> widely deployed as it is.

(and)

(In reply to comment #31)
> Exposure of bug comments to attackers that might lead to disclosure of security
> bugs and a long running series of zero day reports and exploits is one of the
> most catastrophic things that could happen to a large population of firefox
> users and to the mozilla project.   Even if network sniffing of the clear text
> e-mail transmissions is hard, work spent toward that effort his a high value
> target for someone that wants to work against the goals of the project and its
> user base.   High value target + hard to crack access to the information means
> that someone eventually might find the time and methods to exploit.

This makes it sound to me like we're afraid of a MitM attack from someone who pretends to be, say, gmail.com and steals email sent from Bugzilla. Is that correct?

The fear of packet sniffing of any sort is kind of bogus, imo. If some evil person wanted to packet sniff, they could just as easily sniff a forgotten password email they've sent off to my address and simply change my password and login as me. How are we protecting against that?

Likewise, you might argue that this keeps bug comments secure in inboxes around the world in fear of an inbox falling into the wrong hands. Who's ensuring that everyone with security bug access doesn't use the same bugzilla password as they do email password? And, once someone has access to my email account, what's stopping them from, again, simply changing the password of my bugzilla account.

I'm definitely opposed to this change. I read all my bugmail in Gmail for a reason: it's a workflow that is very effective for me. I'm going to now have to visit the bug to view comments each time a bug changes, which will also involve "View[ing] Bug Activity" which just further wastes my time. As someone who works on branch releases, I'm going through lots of security bugs every day and am CCed on probably hundreds of them. Any changes to security bugs, with this change, will add far too much time to my triage. 

Worsening workflow in the name of supposed security doesn't really make sense if you can't prove that things will *actually* be more secure. Can you prove that?

    
    

    
  
> This makes it sound to me like we're afraid of a MitM attack from someone who
> pretends to be, say, gmail.com and steals email sent from Bugzilla. Is that
> correct?

gmail.com or gerv.net or any other domain to which security mail gets sent.

Such attacks are not theoretical. Recently, someone corrupted the DNS for a major ISP in order to launch browser attacks on the users who typoed domains:
http://it.slashdot.org/it/08/08/21/2343250.shtml

I'm sure it's occurred to them that they could use the same trick to get raw material to create a load of _new_ browser attacks.

There have also been (non-DNS-based) attacks on mozilla.org infrastructure specifically aimed at getting a copy of the b.m.o. database. It's a target.

> The fear of packet sniffing of any sort is kind of bogus, imo. If some evil
> person wanted to packet sniff, they could just as easily sniff a forgotten
> password email they've sent off to my address and simply change my password and
> login as me. How are we protecting against that?

By encrypting forgotten password emails. That's in the plan. 

The difference for this attack method is that at least you notice it next time you (try to) log in.

> Likewise, you might argue that this keeps bug comments secure in inboxes around
> the world in fear of an inbox falling into the wrong hands. Who's ensuring that
> everyone with security bug access doesn't use the same bugzilla password as
> they do email password? 

I would expect people not to be using the same Bugzilla password as GPG private key password, certainly. Hopefully, people in the security group are reasonably security-aware.

> Worsening workflow in the name of supposed security doesn't really make sense
> if you can't prove that things will *actually* be more secure. Can you prove
> that?

I don't think it's possible to deny that they will be more secure. Your question seems to be whether the added security actually protects against attacks anyone is going to attempt to mount. I think the link noted above answers that question.

If you want to continue using Gmail, simply install FireGPG <http://getfiregpg.org/>.

Gerv


    
    

    
  
This is no longer blocking the 3.2 upgrade, per Justin and Shaver, and will not be included in it.  It will go in after we fix it up.  This will be top priority for at least myself (and probably Max) until it's ready.
No longer blocks: bmo-upgrade-32

    
    

    
  
Just for expectations, I'll be surprised if we can't have something much nicer in a week or so, although we've been given longer than that.

    
    

    
  
(In reply to comment #97)
> > login as me. How are we protecting against that?
> 
> By encrypting forgotten password emails. That's in the plan. 

Ah? Really?

    
    

    
  
(In reply to comment #96)
> This makes it sound to me like we're afraid of a MitM attack from someone who
> pretends to be, say, gmail.com and steals email sent from Bugzilla. Is that
> correct?

That, or someone who hacks into your real gmail account as recently happened to security researcher "pdp".

> I'm definitely opposed to this change. I read all my bugmail in Gmail for a
> reason: it's a workflow that is very effective for me. I'm going to now have to
> visit the bug to view comments each time a bug changes,

There's no doubt it's going to suck for workflow, security always does. That damn lock on my front door gets in my way every time I'm coming home with a load of groceries.

In addition to FireGPG, if you use IMAP to access GMail you could then use Enigmail. Neither really solves your searching problem, but do you really search bugmail content?

    
    

    
  
(In reply to comment #101)
> That, or someone who hacks into your real gmail account as recently happened to
> security researcher "pdp".

  As many people have pointed out, if somebody can get into your email account, then security on nearly every single website in the world is nullified.

> There's no doubt it's going to suck for workflow, security always does. That
> damn lock on my front door gets in my way every time I'm coming home with a
> load of groceries.

  And probably gives you more of an illusion of security than actual security. But it will protect you from casual attackers.

> In addition to FireGPG, if you use IMAP to access GMail you could then use
> Enigmail. Neither really solves your searching problem, but do you really
> search bugmail content?

  I know more than one person who uses gmail as their primary search mechanism for bugs.

    
    

    
  
(In reply to comment #100)
> Ah? Really?

Yes, really :-) I'm expecting the properly-written patch that people keep talking about to encrypt that mail, and possibly whine mail too if it leaks.

(In reply to comment #102)
>   As many people have pointed out, if somebody can get into your email 
> account,
> then security on nearly every single website in the world is nullified.

And that needs to start changing. If password reset emails and security bugmails are encrypted, I can't see how an email account compromise can lead to a Bugzilla account compromise. Can you?

> > In addition to FireGPG, if you use IMAP to access GMail you could then use
> > Enigmail. Neither really solves your searching problem, but do you really
> > search bugmail content?
> 
>   I know more than one person who uses gmail as their primary search mechanism
> for bugs.

Then we need to improve Bugzilla's search mechanisms :-)

Gerv

    
    

    
  
i disagree with the statements ``there a other sec. bugs so why worry fix *this*''

basically killing exploit vector that clueless skript kiddies can use may somewhat improve bugzilla security.

of course a lot of other exploit vectors remain, mainly because the internet + web + most warez are a kludge over a patch over a design flaw over a century old RFC

    
    

    
  
There is now a SecureMail Bugzilla extension which provides this functionality:
http://bzr.mozilla.org/bugzilla/extensions/securemail/

It is hoped that we may be able to turn it on on b.m.o. when we upgrade to 4.0.

Gerv

    
    

    
  
Sometimes it takes long time to realize counterintuitive stuff :-)

    
  
Blocks: bmo-upgrade

    
  
Assignee: gerv → dkl
Whiteboard: [wanted-bmo](asap) → [bmo4.0-resolved]

    
  
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: