Open Bug 1372414 Opened 7 years ago Updated 2 years ago

Check newsgroup URL security

Categories

(MailNews Core :: Networking: NNTP, defect)

defect

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [regression:TB52])

Bug 1364723 loosened newsgroup URL security, to keep a certain mis-designed UI working. That UI should be fixed in bug 1372411.

Here, we should check whether the change in bug 1364723 allowed actions to be performed that news posters should not be able to do.

There are already 2 actions known that are possible now and should not be possible:
* Poster can include a link that triggers a news store purge
* News message can access messages from another news server. NNTP is not only newsgroups, but can be accessing private NNTP servers for company-internal material. (Some information on NNTP servers has even be subject to law suits, see e.g. https://www.jwz.org/gruntle/rbarip.html for laughs.)
This bug is not only to fix the above 2 known problems, but to investigate which other actions can be triggered by NNTP.

Or to just disallow NNTP -> NNTP loads again, as before bug 1364723. In that case, no investigation needed.

Bug 1364723 was only about "Click here", and that should be fixed by bug 1372411, so we should be able to tighten up again.
Might also need to implement GetPrincipalSpec() again.
(In reply to Ben Bucksch (:BenB) from comment #0)
> Or to just disallow NNTP -> NNTP loads again, as before bug 1364723. In that
> case, no investigation needed.
No. Generally you want to *allow* such loads, as we always have, and no security bounty hunter has complained. You need to read through all of bug 1364723, for example bug 1364723 comment #20. 

> Bug 1364723 was only about "Click here", and that should be fixed by bug
> 1372411, so we should be able to tighten up again.
No, see above.
(In reply to Ben Bucksch (:BenB) from comment #1)
> Might also need to implement GetPrincipalSpec() again.
No, that wasn't really useful since it had the premise that we control news: URLs like we control mailbox: and imap: URLs. The code removed here
https://hg.mozilla.org/comm-central/rev/e915a8b2f1f505d7c4fa1820f35ce99d1164b293#l2.12
was wrong to start with when it got added for bug 1347598.

A brief look at some of the news: URLs out in the wild documented here
https://dxr.mozilla.org/comm-central/rev/69cff0b91c931f7af4270ce3ae057c577f037e87/mailnews/news/src/nsNntpUrl.cpp#59
shows that the
  news://server:port/folder?group=ggg&key=nnn [ &part=ppp &filename=fff ]
was just 100% naïve.

As pointed out in bug 1364723 comment #29, news: URLs can also be:
<news:lJGdnWgY2eWzCanQnZ2dnUVZ_tydnZ2d@mozilla.org>
(In reply to Ben Bucksch (:BenB) from comment #0)
> There are already 2 actions known that are possible now and should not be
> possible:
> * Poster can include a link that triggers a news store purge
Yes, bad, covered in bug 1372411.

> * News message can access messages from another news server. NNTP is not
> only newsgroups, but can be accessing private NNTP servers for
> company-internal material.
Maybe I'm ignorant, but I don't see a problem here. You can publish a public web page or send someone an e-mail with this content:
<a href="https://intranet.company.com/company-secrets/top-secrets/top-secret-no-1.html">Top Secret No. 1</a>.
Any visitor of that web page or recipient of the e-mail can click the link and only *privileged* users will see the privileged content.

IMHO, news is no different. I don't know which further investigation you'd like to conduct, but to me this bug is not actionable and should be closed.
Hello Jörg, please avoid knee-jerk reactions like your comment 3. I agree that the old code was wrong. I didn't ask to resurrect the old code (which your argument presumes), but I asked to re-implement GetPrincipalSpec() again, properly this time.

See initial description: "News message can access [or load] messages from another news server" should not be the case, but currently is.

> Any visitor of that web page or recipient of the e-mail can click the link and only *privileged* users will
> see the privileged content. IMHO, news is no different.

Yes, maybe. We might decide to leave this open.

But only to load (trigger the display of that message to the user in a window), not to read (e.g. load it as JS file or image and process its contents - independent from the fact that JS is disabled in mail and news messages anyways).
> But only to load (trigger the display of that message to the user in a window),
> not to read (e.g. load it as JS file or image and process its contents - independent from the fact that
> JS is disabled in mail and news messages anyways).

To clarify: I assume that is already the case.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.