If The issue does not directly apply to MeeGo platform-self, we get more sense about incident report and infrastructure security, that's not a bad thing:-)
>True, but again, I fail to see how this applies to MeeGo. Obviously we >need to have good security and procedures around system access, and >I'm sure that both Nokia and Intel's expertise in securing systems >will be invaluable here, and obviously I would love it if Nokia or >Intel would buy a bunch of hardware tokens that contributors could >acquire for a diminished price (Vasco would be the cheapest provider, >with batches going for around $12-$16 per unit, second would be [my >previous company], third would be RSA), as having OTPs would have >rendered the Apache attack useless, but I doubt we are anywhere near >such measures. But I am interested in what you talking here. Beyond the HW tokes ( that's depended on HW platform, if SW stack exists, possibly team need to port it to MeeGo), why you don't think "both Nokia and Intel's expertise in securing systems will be invaluable" What kinds of expertise we need to secure system by your suggestion? HW can't handle most attacking in real world, any recommendation for software or system perspective? Thanks&Regards Xiaoning -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sebastian Lauwers Sent: Tuesday, April 13, 2010 4:59 PM To: Ware, Ryan R Cc: MeeGo Dev List Subject: Re: [MeeGo-dev] MeeGo Security On Wed, Apr 14, 2010 at 8:12 AM, Ware, Ryan R <[email protected]> wrote: > I wanted to ask everyone on the developer list to take a moment and review > the incident report that the Apache Infrastructure Team just issued: > https://blogs.apache.org/infra/entry/apache_org_04_09_2010 Sure > I don't ask this to bag on Apache or JIRA or any other entity mentioned in > the incident report. Apache was the victim of a targeted attack and that > can and has happened to many well known entities on the net. But, why? I fail to see anything in that report that isn't a regular XSS attack, that has been worsened by the fact the administrators failed to implement proper salting in their password hashing algorithm. I assume this was due to legacy code running, rather than a design specification, but any new system ought to be using random salting which highly limits the risk involved with losing the password hash database to an external entity. The matter of fact is that none of this applies specifically to MeeGo. Maybe it does at an infrastructure level, but then we are only as secure as the tools we deploy, but it definitely doesn't apply to the MeeGo platform. There are millions of more important security aspects that we could discuss about the Platform Security before we start asking questions about the infrastructure security. Also, please note that Apache is a project that has much more exposure than MeeGo, and this probably will be the case for a very long time. > I think one key items that the incident report does not mention is that if > the attackers had not taken the aggressive step of resetting passwords on > the compromised system, it is very possible the intrusion would still be > undetected. True, but again, I fail to see how this applies to MeeGo. Obviously we need to have good security and procedures around system access, and I'm sure that both Nokia and Intel's expertise in securing systems will be invaluable here, and obviously I would love it if Nokia or Intel would buy a bunch of hardware tokens that contributors could acquire for a diminished price (Vasco would be the cheapest provider, with batches going for around $12-$16 per unit, second would be [my previous company], third would be RSA), as having OTPs would have rendered the Apache attack useless, but I doubt we are anywhere near such measures. > Thanks for taking the time out of your busy lives to raise your security > awareness. Thanks for the offer, but how exactly do you propose to take anything from this incident report and apply it to MeeGo? Niels, correct me unless I'm mistaken, but we do apply the latest patches on our tools, right? Other than that, Ryan, what would you propose we do? Niels and Reggie, maybe having a bit more information regarding the following will put some minds at ease: Does the bugzilla version we are running have a known XSS vulnerability? No. Does the vBulleting version we are running have a known XSS vulnerability? No. Does the CMS have a known XSS vulnerability? (Couldn't find any information) Does each application use its own set of database credentials? Does the database run off the same machine as the web services? What kind of other services run on this machine? Is a subset of these services public, and does it use the OS users for authentication? Are there any users that own sudo powers? Do we have a network and infrastructure topology somewhere? Would it be possible to ask for something like that to be put on the wiki? If this really appears to be a concern to the community, I believe transparency is always the better approach. I think everyone can understand how much admins hating their system when it's not their idea, there may indeed be vulnerabilities, even though I highly doubt it. -- question = ( to ) ? be : ! be; -- Wm. Shakespeare _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
