Spammers, Attachments, Bugzilla, Security, IE, Grrr

Spammers have started attaching copies of their pills ‘n’ porn ‘n’ pump ‘n’ dump pages to Bugzillas, and using the resulting attachment URLs in spam, to get around domain blacklists. The versions attached have an obfuscated JS redirect in them which takes the user to the main spammer site. Example.

How do we combat this while giving the least inconvenience to legitimate users?

We can distinguish genuine users from “unknowns” by saying that anyone with any sort of permission bit (e.g. canconfirm, editbugs) is a genuine user. But that doesn’t help the first-time bug filer. A ban on uploading attachments for them is very intrusive – they may have a screenshot or logfile or something they want to include.

The obvious fix is to say “OK, if you upload an attachment with any MIME type rendered by the browser which can contain script, we’ll switch the type to text/plain; then a triager can come and put it back if they agree the upload is genuine.” Neat and simple.

However, that founders because of IE’s words-fail-me content sniffing, which will happily render HTML served as text/plain, because it thinks it knows better than you. Grr. Snarl.

Not-as-good plan B is to invent our own MIME types, application/x-bugzilla-upload-text and
application/x-bugzilla-upload-binary, which was set on all uploads from non-permissioned people by default. When actually serving the content, we’d detect IE and serve Content-Disposition: attachment (to force download), and for anyone else we’d use text/plain or application/octet-stream, as appropriate.

Anyone got any better ideas?

22 thoughts on “Spammers, Attachments, Bugzilla, Security, IE, Grrr

  1. Why not simply force login to view uploaded files? That way it would be no use to spammers (because victims won’t login), but everyone who needed to view the file would be able to. Unless I’ve missed something…

  2. To get around IE’s type sniffing, how about delivering the attachment as HTML but escaping all the angle brackets and ampersands? You could provide a Save button at the end, in case someone wants to have a copy of the original HTML on their computer.

  3. Or require that the referer for viewing attachments is a bugzilla page, though admittedly the paranoid that have disabled referer passing would never be able to see attachments.

  4. Bots often pass referrers, so that doesn’t really work.

    One option is to restrict signup to use a human verification test (simple math problem, captcha, email confirmation, etc.)

    Another is to use some sort of hashcash solution… a computationally expensive operation that delays things for only a few seconds on the user end. For a spambot that would really restrict their ability.

    Since this is bugzilla and not an protocol like email, as long as your JS works across browsers your golden. It didn’t work in Email because not all email clients would adopt such an idea.

  5. Robert: I suspect the signups are done manually. Remember, they require email confirmation. And you only need one. Also, there are not many attachments – it’s not a spam problem – so the hashcash solution doesn’t work.

  6. “Bots often pass referrers, so that doesn’t really work.”

    We’re trying to prevent attachments from being used as spam. Recipients of spam won’t be sending bogus referrer information to Bugzilla.

  7. Instead of messing with the mime types, you could use the Content-Disposition header to force IE to ‘save as’, until the upload has been checked.

  8. re Content-Disposition… next time I’ll read the *whole* article before replying. Doh.

    stv: munging content only helps a bit, these are uploads on bug reports, you probably want to see the raw content somehow, but without it tripping up your browser.

    Ok a proper suggestion thats not been made already: serve the unchecked downloads in a zip file. Its easily done and you can serve up a canned warning message in the zip as well.

  9. Hmmm,I think the referer solution + verification is best. The referer won’t necessarily be blank (if it’s from some webmail apps), but you only need to check if it’s from a bugzilla domain. Once it’s verified, of course, you can drop the referer check.

    If somebody tries to view the attachment pre-verification with a blank or invalid referer, then they should get a message like “[red]Warning![/red] You may be a victim of spam. Only open this attachment if you are a bugzilla user.” in the middle of an otherwise completely blank page. Every victim will see that message, while almost no valid bugzilla user would see it.

    ([sigh] Spammers make life so boring…)

  10. Why don’t you monitor uploads from new users before they are published (new means they didn’t got a ‘this is a human’ flag).

  11. Personally, I think a combination of referer and login will work. The paranoid who disable referers will have to register, or re-enable referers, and registered users will be recognized as such and can still have their referers disabled.

    In other news, I just got about 4 emails like this through my spamfilter, but using imageshack instead. This is really really annoying.

  12. Why not require some sort of captcha for users without a permission bit (or an accepted bug)?

  13. Sam: thanks, but that doesn’t help because they use JS to obfuscate. It’s easier for wiki markup because script isn’t allowed.

    Another reason referer isn’t going to be too effective: cross-domain HTTPS referers don’t get sent, so if they have secure webmail, we won’t even get a referer in that case.

  14. I have to agree with Huw, requiring an account at “Bugzilla@Mozilla” in order to view attachments should be enough to cut the effectiveness of this technique to zero, at which point I suspect that the spammers will give up trying.

    Of course, preventing it in the first place would be better, but this wouldn’t be a disruptive way to mitigate the problem until a preventative solution is found. I would imagine that there few people who want access to Bugzilla attachments but don’t have an account or are unwilling to register.

  15. Maybe Bugzilla could monitor if a large number of non-loged-in users start viewing a particular attachment? Most legitimate users will have an account, so this scenario should be very indicative of SPAM (unless maybe slashdot posts an article referring to a particular bug).

    Also, won’t the normal flow of bug triagers and QA people quickly identify a new bug as SPAM, and then the spammer’s account and attachments can be deleted?

  16. Or require that the referer for viewing attachments is a bugzilla page, though admittedly the paranoid that have disabled referer passing would never be able to see attachments.

    Bots often pass referrers, so that doesn’t really work.

    We’re trying to prevent attachments from being used as spam. Recipients of spam won’t be sending bogus referrer information to Bugzilla.

    Jesse: but if they click a link in an email, Referer will be blank, right?

    Right, so if there is no referrer, Bugzilla could redirect users to the bug page instead of the attachment. That way, legitimate Bugzilla users could still just go to the attachments table, whereas spam recipients would think “WTH is this?” and likely close the page. Or, we could go one step further, and only redirect when there is no referrer and the user is not logged in (since spam recipients likely won’t have an account).

    And after writing this, I just noticed that voracity and Gijs already suggested the same thing…

  17. James: triagers wouldn’t notice; they seem to put their attachments on long-closed or long-dormant bugs. Your “crowd detection” algorithm probably would lead to false positives.

    I think referer-based solutions would be too intrusive.