On 3 April 2013 14:39, Rob Weir <robw...@apache.org> wrote: > We're starting to take a deeper look at what is required to integrate code > signing into the OpenOffice build and release process. As you probably know > operating systems, especially Windows and MacOS, are now checking for > digital signatures and by default prevent users from installing programs > that are not signed. We see similar checks being integrated into > anti-virus scanners and even web browsers now. > > One of the things that has come out in discussions is how large a target > OpenOffice is, to hackers. We're on track to have 50 million downloads in > our first year. If someone is able to get a virus or a trojan into our > code, they have the ability to cause a huge amount of damage. And if we > are also signing our code, then this damage can propagate even faster, > since the OS's "let down their guard" somewhat when dealing with signed > code. (Signed code == trust). > > Of course, none of this has ever happened with OpenOffice, but with the > stature and reach we have, it is reasonable to believe that we could be a > target of opportunity for someone wishing to cause trouble. We should > always keep this in mind and make sure that we are taking reasonable > precautions to prevent this from happening. > > One vulnerability, in theory, is that we have over 100 committers (123 to > be exact) who have permission to modify the source code in Subversion. > Each account is protected by a self-selected passcode. It is not clear to > me that we even have requirements on password complexity or expiration > policies. In any case, the weakness of this approach is not necessarily > what you might think -- brute force attack on the password. If someone > wants to initiate a "spear phishing" attack against a committer, it would > be something like: > > 1) Standard phishing: a spoofed note from Apache Infra, with some invented > story that asks you to change your password but first enter your old one > for confirmation. It leads you to a fake, non-Apache website. > > 2) If you use the same passcode on multiple web services and one of them is > compromised, say by retrieving the passcode hashes, then it is easy to do > offline dictionary attacks (rainbow tables, etc.) and figure out your > Apache password. > > 3) If you lose control of your laptop, at a conference, bar, hotel, > whatever, even temporarily, someone can gain access to your Subversion > account, via applications that cache credentials, like TortoiseSVN. > > 4) Similar to #3, but by taking control of your laptop via remote means, > i.e., via a virus loaded on to your machine via another vulnerability. >
None of these things have happened to us yet, but all of these things are > possible. > > So how do we reduce this risk? There are a few things we do or should be > doing already. > > 1) Be careful on the machines that you use Subversion from. Treat it like > a machine where you access your bank account from. If you are visiting > risky sites or downloading and installing software from dubious places, > then you are putting your Apache account at risk. > > 2) Use a high-complexity Apache passcode, one not used by you on any other > service. > > 3) Change your passcode periodically, say every 90 days. > 4) On laptops be sure to set a strong login password, but also where > available also a separate harddrive password. These should also be strong > passwords, not reused, and should be periodically changed. > > For those who are building binaries for distribution, the above guidance is > even more critical. > > Of course, we also protect the code through our CTR process. All active > coders should be subscribed to the commits list and should be reviewing the > changes that are made there. Trust the code, not the person. Remember, if > we ever are attacked then it will be through someone's compromised > account. So if you see an odd check-in, say, from Juergen, don't just > accept it saying "Juergen knows what he is doing". If it is odd, then it > should be challenged. > > All of the above should already be going on today. But I'd like to propose > one change to our current process that will, I think, greatly increase > security. This would be to restrict SVN authorization for the code to only > the subset of committers who are actively coding. We should give this > authorization freely to committers who request it. But today we have 123 > committers, some of whom have never used Subversion, and some (like me) who > edit /site and /ooo-site but never touch the code. So we probably have 90 > or more accounts that don't need access to the source code tree. Since > such used accounts are unlikely to be following the best practices outlined > above (changing passwords periodically, etc.) then they are even more > risky. We lose nothing by removing authorization for those users, in order > to reduce the risk profile. Of course, on request we can easily restore > access. But the idea would be to keep the bullets separate from the gun by > default, to reduce the risk of accidents. > > One way of implementing this would be to look at all commits for the past 6 > months (or 1 year?) and remove authorization on /trunk, /tag and /branches > for those who have not made commits. But preserve authorization for the > website directories. > With the knowledge I have, it should be no problem making 2 types of committers, but I am not sure it would really fit the "apache way". In my opinion, it is fair to say, that if a committer has not made any commits for 6 months, the commit access is placed on hold until requested. But we have to very carefull not make it even harder to become/be committer, compare us a bit with LO, there I can have commit access within less than a day. rgds jan I > > Thoughts? > > -Rob >
