Re: why do iceweasel et al have more frequent security issues?
Andrew Sackville-West wrote:
On Fri, Jul 27, 2007 at 04:49:41AM +0200, Erik Persson wrote:
Andrew Sackville-West wrote:
On Thu, Jul 26, 2007 at 10:52:07PM +0200, Erik Persson wrote:
Anyhow, the basic fact that there is fewer security alerts in Konq makes
this a more secure browser, whether this maybe is because only of a
smaller user base or not.
I'm sorry, and i hate to argue with people, but this last statement
just doesn't fly with me. security alerts are the result of someone
finding a security problem and reporting it. The fact that fewer
security alerts exist does _NOT_ mean that konq is more secure. It
only means it has fewer reported security problems. Now it _could_ be
that this is because there actually _are_ fewer security problems, but
it could _also_ be because no one has _found_ or reported
problems. There's an important distinction there.
The assumption is of course that there is no significant difference in the
ratio of reported security issues to discovered security issues, and I
can't see any reason those should differ.
I can't see any reason why they _should_ differ either, but it is
entirely possible that they do and that's the point.
It boils down to this argument you stated:
"Anyhow, the basic fact that there is fewer security alerts in
Konq make this a more secure browser...."
Yes. You argue that there is no security advantage of a browser having
fewer security alerts, and the difference is all because a larger user
base. However, the larger user base that is leading to more found
security flaws also makes the browser a more interesting target for
attacking.
and that's ridiculous. It doesn't make it a mroe secure browser. It
makes it a browser with fewer reported security alerts. period. There
_may_ be other issues involved and it in fact _may_ be a more secure
browser, but that is not necessarily because it has fewer alerts.
There may be, but if you don't know you can't say there is. And even if
there were such asymmetry you don't know which browser it would favor.
(The assumption that there is fewer reported security flaws in konq
really makes the existence of such asymmetry more likely in absence of
other facts, but it does not "consume" the whole advantage of konq - see
below. On the other hand, current experience doesn't favor the
explanation of differences in the ratio of reported to found security
issues).
The relationship between reported bugs in one piece of software versus
another is directly related to how many of those bugs have been found,
not how many bugs there are. True, there is a relationship between the
number found and the number that exist, but that doesn't mean that
because one has fewer reported bugs that it has fewer bugs. That is,
Well, why not?
the number found will always be equal to or less than the number that
actually exist. But that is all you can know about the number of bugs
in a piece of software -- it has exactly or more than the number
reported. One piece of software could have 1000 bugs with one reported
No. You are arguing about asymmetry again. As I said, you don't know of
any asymmetry, and you don't know in which direction it goes, and you
can't argue that it consumes the whole difference.
while another piece could have 100 bugs with 99 reported. According to
your statement, the software with the 1 reported bug has fewer bugs
than the one with 99 reported but that's not necessarily true.
Well it is not necessarily true, but it is likely to be true.
Anyhow, it is more likely that a browser with more reported security issues
have more discovered security issues. And it is also more likely that a
browser with more discovered security issues have more security issues.
Both, of course, under the assumption that there is no information that
changes this.
yes yes yes... _likely_ sure... given a reasonable assumption that the
number of users, testers and coders involved are sufficient to
effectively test the software, then yes, the one with more reported
issues _may_ be less secure. But that's not what you said. You said
the fact that Konq had fewer reported problems makes it more
secure. You didn't say likely, or reasonable assumed to
be... important distinction.
Since we don't know the true number of security flaws in any software,
we can only make assumptions. I though that was sort of an axiom when
discussing security flaws in software.
I said:
"If there are fewer security alerts with Konq the only reasonable
conclusion, if you don't have strong facts pointing the other way, is
that Konq is more secure, and that this is partly because of better code."
The sentence you cite comes from the fact that it is likely that,
whatever the reason is for the fewer reported security flaws in konq,
the number of security flaws in konq that the hackers are finding (and
not reporting) are likely fewer, and that those hacker found flaws
likely are related to the number of reported flaws.
Compare to os x. There have been some rather severe security issues with
os x, but I haven't heard of any exploit in the wild.
WARNING! CAR ANALOGY!
if we have two cars parked side-by-side and mine is stolen (I'll
take the fall for this analogy ;) and yours is not, does that mean
that your car is more secure? no. it means someone looked for a way
into my car and exploited it. maybe they never even looked at your
It also mean that it is more likely that your car is less secure.
...
If you have 10 cars of type A and 5 of type B and 2 A cars, and one B car
was stolen, you should guess, if no more information was available, that
the cars were about equally secure. No, if you have 10 A cars, and 5 B
cars, and 1 A car was stolen and 4 B cars, you should guess that the B cars
were less secure.
no. you _could_ guess that. But it is equally valid to guess that car
B's, being rarer cars are more desireable and therefore more likely to
be stolen.
Well, If you don't have any information, you *should* guess that the car
type with the larger proportion of stolen cars is less secure. It is the
logical conclusion. It does however not EXCLUDE other reasons. You
should also for example guess that the car type is more desireable, etc
etc. The thing is, without information you can't discriminate between
different reasons, you could only say that all reasons that makes the
car type have a higher ratio of stolen cars are more likely.
The fact that you have a result, makes all reasons increasing the
likelihood of this result more likely.
Now, if you have x A cars and y B cars and you don't know x and y, but you
know that more A cars are stolen, it is more likely that the A cars are
less secure, since there is no reason to believe that x
is larger than y, than believing the opposite.
no, again, you could believe that, but its equally valid to believe
that A cars getting a high price in the chop-shop market. There is
Well, no. If you don't know you can't discriminate between reasons. You
should thus *also* believe that A cars are more desireable. One does not
exclude the other. However since we don't know we have to guess that all
reasons making car type A more stolen also are more likely than the
opposite or the equality between the two types.
END CAR ANALOGY!
a more pertinent fake example.
programmer X finds a security hole in konq that when visiting a
carefully crafted website, allows remote execution of code, privilege
escalation and ultimately results in a box getting
rooted. okay. that's obviously a security problem. but programmer X
doesn't report this problem and no security alert is issued. programmer Y
finds a security hole in mozilla that allows an already
installed plugin at a certain version to escalate its own privileges and
as a result
download and save a piece of code to disk with the name
"execute_me". Now if the user happens to see that file and thinks,
hmmm... I wonder what that is and executes it (after chmod +x) it does
a rm -rf on their home. programmer y reports this security hole and a
security alert is made detailing the problem. now, clearly, the konq
vulnerability is *much* more of a security risk
than the mozilla error, right? the mozilla one requires the plugin be
already installed and the right version and then requires the user to
actually chmod and execute the thing. the konq one just requires the
user to visit a carefully crafted website.
If this would be the case in the mozilla vs konq situation, you have to
explain to me why:
1) konq security issues should be reported at a lower ratio
because the person who found the bug likes knowing the bug and wants
to be able to utilise it to compromise machines, and thus keeps it
under his black hat...
We are not talking about a single case here. We are talking about the
statistics of reported flaws. If your example should have any impact on
the real firefox vs konq case, you have to make it likely that there
exists such a bias in the total statistics of reported bugs and
**especially** that this bias explains the whole observed difference.
2) why security issues in konq are more severe
it was an example showing how your premise that more reported
bugs means less secure. I was showing that the number of reported bugs
is not necessarily related to the security.
IF it should have any impact at all on the number of reported bugs you
must make it likely that there exists such a bias in the real case and
**especially** that this bias is reason to believe that there is no
security difference.
eg. why there should be reason to believe that there is a statistically
significant bias between the browsers in factors such as reporting security
issues and severity of security issues.
because the whole conversation was predicated on the possibility that one
browser has significantly larger mind/eye-share and therefor has greater
opportunity to have problems discovered and reported. Sure there are
some folks looking at fire&iceweaselfox and hiding the vulnerabilities
they discover, but as the crowd of users/testers/coders grows, they
become statistically less significant than they would be for a program
with lower numbers of users/tester/coders.
You have to explain why this should "consume" the whole reported
advantage of konq.
I can see no reason to believe one or the other. I just look at the facts -
there are less security issues reported for konq. The only reasonable
conclusion is that konq is more secure.
no. that is _a_ reasonable conclusion, but by no means the only one.
It is not a reasonable conclusion that konq is less or equally secure,
since we lack other facts. This is what I mean by "only".
but based on what you've written above, because the mozilla one was
reported, then mozilla is less secure than konq. that doesn't add
up. And in fact, in my fake example above, the lack of security alert
makes konq even more of a security problem because 1) the right devs
might not know about the problem to issue a patch and 2) the public
doesn't know about the problem to avoid it until a patch comes along.
As I stated above, you have to explain how this constructed example could
have any impact at all on the real mozilla vs konq case.
I don't have to explain it because it doesn't. it was an example used
to illustrate how your assertion was false. But in fact, I believe
that in fact this sort of thing goes on all the time. An unreported
security vulnerability is _much_ more dangerous than a reported one. A
reported one gets fixed. An unreported one gets exploited.
Of course. But you don't know any of this. You know that there is fewer
reported sec issues in konq. This is reason to believe that konq is more
secure (as well as any other reason giving this result).
You don't know if the security vulnerabilities that are found in konq
are reported to a lesser degree, and especially you can't argue that
such a difference "consumes" the konq advantage.
As I said, if it is a fact that there is fewer security alerts in konq, the
only reasonable conclusion is that konq has less security issues.
nope. konq has fewer security alerts == fewer reported security
problems !== fewer actual problems.
Wrong.
All other
conclusions rely on some sort of asymmetry between the browsers, for
example when it comes to the severity of the reported security issues, the
presumed not found or not reported security issues, in the the ratio of
reported found security issues etc.
But these are all valid possibilities, not certainties. You have
stated that this:
fewer security alerts == fewer security problems
is a certainty. Or at least near enough so as not to be significant.
Yes, it is significant.
It is also what seems to be the normal way of viewing things when it
comes to reported security flaws. Sendmail is believed to be more
unsecure than postfix since sendmail has a larger number of security
issues in the past. Windows is believed to have more security issues
than openbsd since there have been a larger number of security issues in
windows etc etc etc etc etc. This is of course not an argument but
merely an observation.
But its not a certainty. It may, in the final analysis be true, but
until _all_ the security problems from both programs have been found
and counted, then it is not a certainty. It is unknowable.
We are not talking about likelihoods of 1 here. We are talking about
what is more likely, especially since we *never* can no if all security
flaws have been found in a software of reasonable size.
If you were to argue the way you do, you could *never* no if one product
is more secure than another.
If you don't have any facts supporting such kind of asymmetry, you can't
argue that there exist such asymmetry, and especially you can't argue that
such asymmetry is to the advantage of Firefox (it could just as likely be
to the advantage of konq - if it existed).
I never argued that there _was_ such an asymmetry. I provided an
example of how such an asymmetry would make your assertion false.
Yes, but if this would be interesting, you also needs to make this
argument "consume" all the advantage of the lesser number of reported
security flaws in konq.
Note that I have no bias regarding kong and iceweasel.
Also, I'm more than willing to embrace a counter example. OpenBSD has
had two remote holes in the base install in more than 10 years. And
I'm willing to wager that it is in fact probably the most secure OS
out there for common folk to use. BUt that is a special case because
we _know_ that it was built up piece by piece for one purpose -- to be
secure. Security has motivated every decision made about OpenBSD so we
have additional data on which to make the assumption that its number of
reported vulnerabilities is a good indicator of its security
overall. But just pulling two pieces of software out of the air and
comparing their security based on the number of reported
vulnerabilites doesn't work. Not without some additional information
to support those assumptions.
It does. As I said, if you have a result, all explanations making the
result more likely, are more likely. If you don't have any facts making
one or more explanations more likely, you can't discriminate between
them. Take for example the simple, but not equivalent, case of getting
4, 5 or 6 when rolling a dice. If you know you got a 4,5 or 6 (but not
which of them), this increases the likelihood that you got a 5, even if
it is also increases the likelihood that you got a 6 or a 4. You can't
be sure you got a 5 though. If you know that the 4 or 6 are favored,
this *could* consume the whole increased likelihood that you got a 5,
but if you don't know you can't tell.
If you have a strong indicator of security, as the number of reported
security issues, you have to have a strong explanation to "consume" all
the "probability advantage" of the product with the fewer security issues.
A
/Erik
Reply to: