Taint mode

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Taint mode

Gervase Markham
At the last Bugzilla meeting, we discussed turning off taint mode, as
it's a performance hit, keeps breaking 3rd party modules and provides
marginal value now that we use placeholders properly and template escaping.

Someone said a bug had been opened: is that right?

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Taint mode

bbaetz (Bugzilla)
/delurk

What is the measurable performance impact? Any idea whether its in a
specific bit of code or more general? The goal of taint mode is to track
stuff that we don't know about. When I added taint mode (way too long
ago...) we found a huge number of security issue, and that was *after*
doing audits for problem categories. I'm sure that its better now, but its
better to be safe than sorry....

It should just be a check of a single magic bit in the perl code, although
since Perl isn't really my focus nowdays I could be wrong...

Bradley

On Mon, 27 Jul 2015 at 21:00 Gervase Markham <[hidden email]> wrote:

> At the last Bugzilla meeting, we discussed turning off taint mode, as
> it's a performance hit, keeps breaking 3rd party modules and provides
> marginal value now that we use placeholders properly and template escaping.
>
> Someone said a bug had been opened: is that right?
>
> Gerv
> _______________________________________________
> dev-apps-bugzilla mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=bbaetz@...>
>
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Taint mode

Frédéric Buclin
In reply to this post by Gervase Markham
Le 27. 07. 15 12:57, Gervase Markham a écrit :
> At the last Bugzilla meeting, we discussed turning off taint mode, as
> it's a performance hit, keeps breaking 3rd party modules and provides
> marginal value now that we use placeholders properly and template escaping.

It's a performance hit based on which benchmarks? I suppose none has
been run against Bugzilla. If benchmarks have been run against Bugzilla,
then the results should be made public. For instance, Foswiki said that
they see a 10% boost with their code with taint mode disabled:

  http://foswiki.org/Development.RemoveTaintCheckingFromFoswiki

First of all, I would say that a 10% performance penalty is not that
much when talking about security. I don't know which 3rd-party modules
you are talking about, but we certainly don't "keep breaking" them. I
have been involved long enough to know that it's not true.

Secondly, about the use of placeholders and template escaping: we still
catch "insecure dependency" problems from time to time, thanks to
tainting being enabled. I agree, this is much less frequent than in the
past. But Search.pm doesn't use placeholders for its queries, so a SQL
code injection there would be annoying.

Each new release contains new code and this code is certainly not safer
than previous code. Humans still do errors in 2015. This is even more
true now that Bugzilla has an API which lets users interact with it
remotely. It's a new way to attack Bugzilla. Sure, the taint mode
doesn't make your code 100% safe, but it's one built-in security feature
that Perl has which we should use. And assuming you plan to only turn
off tainting on production installations, how would you keep it enabled
in development environments? You cannot simply turn a bit on/off. This
is an important point to consider.

To summarize: wanting to turn off the taint mode solely to make the code
faster is a mistake. In that case, there are better ways to make your
code much faster: replace Template Toolkit by Xslate. So I share the
same feeling as bbaetz here.


> Someone said a bug had been opened: is that right?

For bmo only: https://bugzilla.mozilla.org/show_bug.cgi?id=1186416


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Taint mode

Gervase Markham
On 27/07/15 13:50, Frédéric Buclin wrote:
> It's a performance hit based on which benchmarks?

I agree we do need to run some, and I believe Dylan said he would. But
based on the experience of other people.

> First of all, I would say that a 10% performance penalty is not that
> much when talking about security.

A 10% performance penalty is a lot when talking about anything.

> I don't know which 3rd-party modules
> you are talking about, but we certainly don't "keep breaking" them. I
> have been involved long enough to know that it's not true.

DateTime::TimeZone has broken at least once and possibly twice now
because they don't test with taint.

> Secondly, about the use of placeholders and template escaping: we still
> catch "insecure dependency" problems from time to time, thanks to
> tainting being enabled. I agree, this is much less frequent than in the
> past. But Search.pm doesn't use placeholders for its queries, so a SQL
> code injection there would be annoying.

One option might be to use a different method of enabling taint mode
(environment var?) so that people can enable it for development and
disable it for production.

> Each new release contains new code and this code is certainly not safer
> than previous code. Humans still do errors in 2015.

I agree. The question is: how many of those errors does taint mode
actually catch? When was the last time you got a taint error, and it
actually turned out to be a potential security problem, as opposed to
e.g. running something through detaint_natural before making it the
placeholder value in an SQL query, which would be safe anyway?

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>