
Bugzilla CVE-2015-4499:         All Your Bugs Are Belong to Us - Chris911
https://blog.perimeterx.com/bugzilla-cve-2015-4499/
======
pilif
_> Will the DB raise an exception? Will it crash? No – It automatically
truncates the data so it fits the column size._

If you write software, never be "helpful" and try to fix problems with input
data you can't handle. You have no idea whether the fix you have in mind is
going to be appropriate in all situations and there is no guarantee that your
users are going to acknowledge the warning you might (or might not) issue in
that case (case in point: MySQL does fire warnings, but many libraries don't
even expose them to the user, so even if they wanted to check for warnings
after every statement, they couldn't)

"Fixing" broken input data is nothing but actually corrupting data because
after the fact there is no way to know what the original was, nor is there a
way to know whether the "fixed" data was actually fixed or whether it has been
that way to begin with.

If you are in a position where you can't do something based on the input data,
then _blow up_. That way you help users to avoid ever having to deal with
corrupted data (or all their private bugs exposed to the public like what
happened here)

~~~
dspillett
_> If you write software, never be "helpful" and try to fix problems with
input data you can't handle._

Yep. Accepting bad data in any way is a bug, not a feature, and it isn't
always (I'd suggest it isn't commonly) intentional: for instance mySQL used to
accept dates like 2015-02-30 simply because its internal date format permitted
it rather than because they were explicitly allowing it - it was an accident
not an attempt to be helpful.

Accidental bugs that accept bad data are often indistinguishable from
intentional "help", and can get passed up through a stack of calls (App A uses
library B that wraps library C which calls service D that uses library E...)
so even if the help is very well documented at source that knowledge is
usually lost as you move up the chain and the application dev is left with a
library that accepts bad data unbeknownst to him/her which could end up
masking a serious bug that will bite them later.

 _> "Fixing" broken input data is nothing but actually corrupting_

Exactly. The old "be strict in what you send, but generous in what you
receive" is often misinterpreted - you should only be generous in what you
receive if everything you receive can be properly handled all the way into
your stack and all the way back out again, and never be generous enough to
accept bad data. Back to the date example: yes, accept any unambiguous date
format the user might throw at you, but _never_ accept an invalid date.

 _> If you are in a position where you can't do something based on the input
data, then blow up._

Definitely. If something could fail it should fail as early as possible, and
not quietly in development (caveat: failures should not be outwardly verbose
in production for security reasons), that way you are more likely to catch
problems early, before they compound into something worse.

~~~
josephcooney
I don't think it is quite that clear cut. See, for example, Postel's Law AKA
the Robustness Principle.

Be conservative in what you do, be liberal in what you accept from others

[https://en.wikipedia.org/wiki/Robustness_principle](https://en.wikipedia.org/wiki/Robustness_principle)

~~~
MichaelGG
The Robustness principle isn't, and Postel's Law is pretty much a failure.
This kind of thinking introduces tons of implementation compatibility issues.
By being liberal in accepting from others (aka accepting malformed messages),
you allow broken implementations to "work". Now those broken implementations
form a de facto standard that everyone else must implement.

I demonstrated how this kind of thinking, coupled with "simple" text-based
protocols, introduces security issues. SIP is a protocol with nutty parsing
rules like HTTP. Lines end with CRLF, body is separated from headers by two
CRLFs.

Some implementations act liberal and will accept any combination of CR and LF
instead of just CRLF. So header \r\r body is OK with some implementations, and
not others. Which means some stacks will read body as more headers. It's not
hard to see how this creates a security problem, as you pass a message to a
trusted proxy and it asserts things are OK, except the two stacks don't agree
on what the headers actually are. Oops. This is a real, live, issue that
affects SIP networks today and can be exploited for profit. And it's hard to
fix, because some networks are actually sending non-CRLF lines, creating a
compat issue. If implementations had been harsh on the CRLF requirement, those
networks wouldn't be sending non-CRLF lines, as it would never have worked in
the first place.

In short, being liberal just means "each implementation creates its own
interpretation". This is because not all impls are going to agree on what
"liberal" means. And if "liberal" could be defined, then it should be defined
in the spec! No need for interpretations.

------
vog
I never understood why people use MySQL for anything where correctness is
important. The auto-truncaction is only one of many nasty surprises.

Did you know that auto-truncation also kicks in if your columns values are
small, but you run a CONCAT on them? That was a nasty surprise when a
generated a CSV line on DB side, which by bad luck was truncated immediately
before a comma, so the result was correst, just the jast few items were
missing. And ever looked at the handling of invalid dates? Not to mention what
happens if you forgot to specify a column in your GROUP BY clause, but use it
in the SELECT part ...

To anyone who is so brave to write their application using that database: Be
sure you know all those issues and take care of them in your application. Or
make sure you aren't affected by them. Or, switch to a high-quality database!

I switched to PostgreSQL a long time ago and never looked back. These people
care about exactness, quality and clean extensibility in all directions, even
user-defined index structures are possible (GIN, GIST). The problem that
PostgreSQL was slower than MySQL disappeared as soon as MySQL became
transaction safe with InnoDB, because it was now a fair comparison as
PostgreSQL was transaction safe from the very beginning. Also, the PostgreSQL
project management is one of the best I have ever seen, meeting schedules,
regular commit fests, quality-driven, honest beta releases, and so on.

~~~
rimantas

      > I never understood why people use MySQL for anything where
      > correctness is important.
    

They probaly know how to configure it.

~~~
vog
This doesn't seem to be any harder than MySQL, it's just a bit different. Also
note that PostgreSQL can perform "peer" auth, so you don't have to fiddle with
DB passwords unless you really want to access your DB over a network.

Install package:

    
    
        apt-get install postgresql-9.4
    

Become PostgreSQL admin:

    
    
        su - postgres
    

Create a DB user who is allowed to create databases (assuming your app will
run as user "someuser"):

    
    
        createuser -d someuser
    

Login as that user:

    
    
        exit
        su - someuser
    

Create your database:

    
    
        createdb somedb
    

Play with your database:

    
    
        psql somedb
            CREATE TABLE ...

------
derf_
It is important to point out that access to security bugs (the ones that
contain descriptions of unpatched vulnerabilities) is _not_ automatically
granted to all Mozilla employees, so simply having an @mozilla.com e-mail is
not enough to get information on how to exploit Firefox.

It is enough to get access to potentially sensitive partner information (as
can be seen from the posted screenshot), but those are usually a different
class of bugs from security bugs.

Further, we now classify security bugs by the area of the code they affect,
and give engineers access to just the areas for which they are responsible,
rather than blanket access to all security bugs. This is a process that began
even before the recent attacks, but we have been pushing it more aggressively
in their wake.

------
elchief
1\. This is mostly MySQL's fault for default silently truncating values longer
than the requested length. Postgres and SQL Server don't do this, but that's
all I tested

2\. Lack of email validation by Bugzilla. Emails are max length 254, though
this might not have been official when the code was written. See
[https://stackoverflow.com/questions/386294/what-is-the-
maxim...](https://stackoverflow.com/questions/386294/what-is-the-maximum-
length-of-a-valid-email-address)

3\. Consider using an HMAC'd URL for registration email links instead of
putting a token in the database, as per [https://neosmart.net/blog/2015/using-
hmac-signatures-to-avoi...](https://neosmart.net/blog/2015/using-hmac-
signatures-to-avoid-database-writes/)

~~~
stinos
1\. I copletely agree it isn't exactly the best design decision, on the
contrary, but the developpers are still too blame as well in my opinion. They
chose the datatype so they should have read the documentation, _especially_
the caveats like this, and they should have done something to deal with this.

This applies more generally. There are a ton of programming languages,
standard libraries and APIs out there with
weird/confusing/exceptional/undefined-behavior-invoking types and functions
depedning on how they are used so a sane developper should alwyas check this
and handle accordingly, even though it might lead to more code to handle edge
cases than to the actual expected main code path.

------
ScottBurson
You know, if you're going to use this meme, you should get it right. It should
be "all your _bug_ are belong to us" [0]. Yes, it's ungrammatical -- that's
the point!

[0]
[https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us](https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us)

~~~
EpicDavi
I would argue that in the original, "base" was referring to a singular object
and was not reduced down from "bases" (plural) to "base" (singular).
Therefore, I do not think it is necessary to reduce "bugs" to "bug".

I know you are joking but if we are being pedantic here, "all your swarm are
belong to us", would be more apt.

EDIT: Instead of swarm, a name for a group of bugs (errors) would be
appropriate.

~~~
ben0x539
I don't speak Japanese, but according to whoever translated it for Wikipedia
it was really "bases":

[https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us...](https://en.wikipedia.org/wiki/All_your_base_are_belong_to_us#Selected_transcript)

~~~
gizmo686
Translation is an art.

Japanese does not have plurals in the same way that English does. It does have
an optional pluralizing suffix. However, the fact that it was not used with
"base" does not imply that "base" is singular.

Looking at the sentence structure, it seems to me that "base" was really
intended to be singular (which also fits with the context provided by the
script on your wikipedia link). Roughly the sentence is structured as follows:

By means of the Federation Army's corporation, as for yall's base, entirely
CATS has taken

The word I translated into "entirely" could also be translated into "all".
However, gramaticly, it still does not modify "base", so I can see no sense in
which "all your bases" is a correct, literal translation.

~~~
gohrt
The Wikipedia translation disagrees. Add your information to the page, please.

------
kijin
I'm not sure which is worse: not validating your data, or silently truncating
invalid data.

It seems that the fix [1] was to limit the length of email addresses to 127
characters. That'll do for the time being, but they really should pay more
attention to database warnings. MySQL does all sorts of stupid things, but at
least it tends to emit warnings when it's being stupid. Catching those
warnings and turning them into exceptions should go a long way toward
preventing bugs like this.

[1]
[https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=commitdif...](https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=commitdiff;h=9d64d15)

~~~
harshal
It looks like the devs are doing exactly the right thing: Fixing the immediate
problem quickly on released branches and following up by stricter checking in
the development version (which looks like it will need a lot more changes)
See:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1202447#c17](https://bugzilla.mozilla.org/show_bug.cgi?id=1202447#c17)
[https://bugzilla.mozilla.org/show_bug.cgi?id=1202509](https://bugzilla.mozilla.org/show_bug.cgi?id=1202509)

------
fein
Incredibly interesting, and incredibly simple. Very cool stuff.

I do wonder... Why on earth is domain based privileges _ever_ a good idea?
There should be a proper roles system behind the scenes which doesn't grant
privileges based on an email domain.

~~~
geofft
Because the business requirement is "Anyone from this company we are
partnering with, which has signed a mutual NDA at the company level, should be
able to see these bugs," and "The local Bugzilla admins shouldn't be involved
in the hiring processes of that other company," and "No, they don't have a
public facing identity management system we can integrate with."

------
tomvangoethem
For anyone interested in similar issues: here you can find a report for a
vulnerability in Phabricator with exactly the same cause (truncation by
MySQL), and pretty much the same result:
[https://hackerone.com/reports/2224](https://hackerone.com/reports/2224)

If Bugzilla would allow non-ASCII characters in the email address, MySQL's
truncation behaviour with astral symbols (e.g. 𝌆) would probably have lead to
a similar vulnerability as well. (It did so in Phabricator:
[https://hackerone.com/reports/2233](https://hackerone.com/reports/2233))

------
bugmen0t
The bug impact description is completely false. Mozilla has "corporate
confidential" bugs behind the @mozilla.com email check, but everything with a
security rating is restricted to specific accounts that have been explicitly
vouched for.

