[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#496429: The possibility of attack with the help of symlinks in some Debian packages

On Mon, 2008-08-25 at 11:57 +0400, Dmitry E. Oboukhov wrote:
> NW> An attacker would be insane to select this example as a
> NW> vehicle.
> Attacker can use many ways (all variants from this list, for ex), one of
> its can work. Why you think that this variant is not work?

Because it is in the documentation, not the script. Didn't you read the
reply? It is not a route of attack, it is AN EXAMPLE in the

What kind of attacker is going to assume that a particular user not only
has the package installed but has also chosen to use this specific one
of a couple of dozen examples available in the doc package that goes
alongside this one package, to create a particular file which is itself
part of a process that even the most regular user operates once a month
at most *and* that the user has not implemented the example in some
other script that does various other checks? The number of users who
need this particularly specialised example is very small (which is why
it is not implemented directly within dfxml-invoice). An attacker would
be insane to select this example as a vehicle. The whole point of the
package is to support the use of the data in a wider variety of scripts,
written by users for themselves. The example exists to show what can be
done, not what every user is expected to do.

Stop blindly applying your (broken) logic and *think* about the bugs
that you are filing, Dmitry.

The example is only a problem if a user implements the documentation
without thinking *and* uses it on a multi-user system. The idea that
this is a grave security issue is ludicrous - you might as well assert
that all interpreters must be withdrawn because they can be used in
security attacks. I know, let's ban all means of file storage because
files can be used in attacks - even better, ban all methods of executing
the content of any file, whether in RAM or in storage. No, wait, that's

Blind application of logic will end up with a ban on oxygen because it
is fatal to all life on earth. The logic is correct, even if all human
disease is cured, oxygen will cause the death of every human on earth
(over a sufficient period of time) due to the role of oxygen radicals in
the ageing process, it still doesn't mean it is correct to apply the
result of that logic. 

If you extrapolate pure logic far enough, every possibility becomes
probable. If you allow enough time, every probable risk becomes a
certainty. You can't use blind logic to assert risk, the logic must be
tempered within the bounds of what is reasonable, what is likely and
what is realistic. 

IMHO, the risk of bugs (including quite a few security ones) due to
time_t overflowing in 2038 is far more likely than a real security issue
from #496429. That is why pilot-qof (via the QOF library) has 64bit time
handling on all platforms but this rather innocent example. It is *not*
reasonable to say that even 64bit time is insufficient and that all time
must be 128bit or 1024bit or gigabit etc. 64bit already includes enough
seconds to encompass a couple of dozen times the (estimated) age of the
universe, 32bit time_t comes to an abrupt end in 2038. This about
proportionality, reasonable risk and a realistic assessment of security

Security measures *must* be proportional to the actual risk. That is the
main the problem with this mass bug filing, the security implications
are not equal across all packages which have had RC bugs filed against

Just because your (broken) script has found a pattern, does NOT mean
that the pattern is a security risk - it is incumbent on YOU to check
the output of each individual pattern match in each individual package
and make a sane determination of the actual risk of that pattern in that
package. The bug should then detail the *specific risk* within that
package, an assessment of why that specific risk in that specific
package is actually a problem for that specific package within the
normal behaviour of that package. With a release so close, filing RC
bugs without due care is, as Steve described in #496386, simply not good

"This is far below the quality I expect from a mass bug filing that's
been reviewed by debian-devel. Mass bugfilings at RC severity need to be
held to a much higher standard than this, particularly when we're in the
middle of a release freeze."

I take Steve's point that the example could be improved (although I'm
not entirely sure what form the change should take so as to not
obfuscate the example in security warnings). Such a request for an
improved example is NOT a security issue or an RC bug! There is no way
that this example should delay the release of Lenny.

I'm tempted to close all other bugs filed during this mass bug filing
against packages that I use without any further comment or fix or
explanation, simply because the mass bug filing itself is so
unreasonable. Why should I invest the time trying to determine if the
bug is an actual risk when, so far, I have found all instances to have
been filed without sufficient care or diligence?

If the submitter doesn't care about checking if the bug is real or
imagined, why should I believe that the risk is real? Your lack of due
diligence has invalidated the entire mass bug filing attempt and
undermined every bug you have filed for this supposed problem.

IMHO, the only acceptable response to this inept bug filing is for you
to immediately close all the bugs you have filed under this mass bug
filing so far, go back to the beginning and take the time to make an
individual assessment of the individual risk of each package and script
that your process has so far identified. Then, in the accepted manner,
using '/usr/bin/mass-bug' from devscripts, you post again to
debian-devel, including a detailed list of packages, maintainer and
uploaders (mass-bug does this for you) against which you PROPOSE to file
bugs and give time for responses. According to the responses, you
optimise the process further and repeat until there is a consensus that
the methodology has done everything reasonable to exclude false
positives (including not scanning patterns within embedded documentation
like POD). Then, you individually file each bug with a clear description
of the problem as it applies to that specific package and you set the
severity and tags appropriately for each individual bug. During this
process, you may well generate a patch that fixes the problem and you
can then attach that to the bug report.

This is what I have been doing for the long term mass bug filing for
crossbuilding support that I started in November 2007 and which will
continue until probably just before the release of Lenny+1.


      * 59 Outstanding
      * 2 Pending Upload
      * 39 Resolved

I don't care that it takes longer, it gets better results and is the
right way to do a mass bug filing.


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: