On 4/3/13, 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.
Thoughts?
-Rob
--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
