Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Most developers have only the vaguest idea of what the security
implications of symlinks are, and simply saying "this seems a tad too
restrictive" does not instill confidence that you've spent the time to
become an expert on this obscure and complicated subject.
-- Matt
Mackall
The implications of this vulnerability reach from disclosure to loss of
personal information for the Calendar data. For Contact information,
private information of others is also affected, potentially including phone
numbers, home addresses, and email addresses. Beyond the mere stealing of
such information, an adversary could perform subtle changes without the
user noticing. For example, an adversary could change the stored email
address of the victim's boss or business partners hoping to receive
sensitive or confidential material pertaining to their business.
-- Bastian
Könings, Jens Nickels, and Florian Schaub on an Android vulnerability(Log in to post comments)
Security quotes of the week Posted May 20, 2011 8:00 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Well, reading the whole email thread, this Matt Mackall seems to be a very arrogant and uncooperative guy, whose touting his horn but does not the necessary steps to actually improve hg's security. After all, that would mean to educate his co-developers with his knowledge, not belittle them.
That's actually a problem with many security-focused guys, and IMHO one of the reasons why we don't get better security in our systems.
Security quotes of the week Posted May 20, 2011 10:22 UTC (Fri) by anselm (subscriber, #2796) [Link] Well, reading the whole email thread, this Matt Mackall seems to be a very arrogant and uncooperative guy, whose touting his horn but does not the necessary steps to actually improve hg's security. The original poster's apparent problem was that Mercurial's security was too good (so he didn't get to use symbolic links like he wanted). It's not Matt's fault that the security problems inherent in allowing symbolic links inside repositories didn't occur to the original poster. One may reasonably disagree with Matt's tone in places, but I don't see how one can blame Matt for not improving the security of Mercurial when it is his attention to security that caused the original poster's »problem« in the first place. How exactly does allowing symbolic links in the way the original poster suggests »improve« Hg's security?
Security quotes of the week Posted May 20, 2011 11:04 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Obviously I expressed myself not good enough, since you misunderstood me.
I don't blame Mackall for not vetoing the proposed symlink-related change. To me it's clear that it should not have gone in; though obviously that was not the case for his fellow co-developers. I noted his attitude that he didn't see it necessary to explain *why* it's a bad idea. His style is management-by-appealing-to-authority without backing it with the (existing) facts.
In particular, he's going completely off in his later emails where he tells that he made a test hg repository that reputedly "0wnz0red" a system (his term, not mine); but refused to explain how he did so, so that the others can also learn to take such problems into account when they write or change code. Read the thread starting at http://thread.gmane.org/gmane.comp.version-control.mercur... . (I found it remarkable that this is another appeal-to-authority-style post: one has to take his word and the one-line output that the system really has been take over -- whatever that means in that context.)
Anyhow, I'm not involved in hg development and don't know anyone of these guys. I must emphasize that this is in no way an attack Mackall on a personal level; I don't know him at all. I commented on his project-related behavior shown in that email thread and just on that, because it is an exemplary incident of a greater problem.
I think the point that I actually tried to make is that this is a great example how *not* to enhance security in one's system during development. I belong to the persons that follow Bruce Schneier's thesis that security is not a state, but an ongoing improvement process. And a very important part of this process in the software development phase is developer education. Yes, Mackall prevented that this change goes in. This keeps the software system security _on the same level_ as it was before, it does _not_ improve it. But he *could* have improved the software project security process by educating his peers. Instead he chose not to do so, and that with full intent. He doesn't express it explicitly, but if I read his emails they simply tell the others "you are too stupid to learn that, go away". IMNSHO, this is *not* the way to improve security; this is eventually the opposite.
And this kind of project work and communication style I've seen with too many security "professionals"; it was one of the reasons why I left the security field some years ago.
Security quotes of the week Posted May 20, 2011 13:18 UTC (Fri) by anselm (subscriber, #2796) [Link] I noted his attitude that he didn't see it necessary to explain *why* it's a bad idea. His style is management-by-appealing-to-authority without backing it with the (existing) facts. Matt also said that it's not really cool for project leaders to post their own 0-day 'sploits with vulnerable clients still out there. So not yet. which I read as an intention to explain the issue in more detail in due course. I've been following Mercurial development, off and on, for a while (as an interested onlooker, mostly) and I have generally found Matt to be a fairly reasonable person. He could be a lot worse. He could be Dan J. Bernstein or Theo de Raadt :-)
Security quotes of the week Posted May 20, 2011 15:02 UTC (Fri) by jschrod (subscriber, #1646) [Link] Matt also said thatWell, I didn't understand that, so I ignored it. :-). The OP on the mailing list wanted to revert a change from 2007, so this is not a new introduction but the behavior of hg since 4 years. I didn't understand how there could be a newly introduced vulnerability by a change that didn't get applied.it's not really cool for project leaders to post their own 0-day 'sploits with vulnerable clients still out there. So not yet. But then, as I wrote, I don't follow hg development, so there might be some deeper insight that I'm missing. Were it not for XEmacs, I wouldn't even use it. ;-) I wanted to comment on attitude and their appeal, not on security facts. The latter are undisputed.
Security quotes of the week Posted May 20, 2011 14:04 UTC (Fri) by Kwi (subscriber, #59584) [Link] One should read Mackall's follow-up, which is Quote-of-the-week stuff in its own right:
|
|||||||||||||