Paulo,
este é um assunto muito polêmico.
Ter código aberto ou fechado não garante segurança.
A pergunta tem que ser diferente: "Por quem e como o sistema será (ou
tem que ser) auditado?", nada impede de vc utilizar uma solução aberta
como se fosse fechada.
Outra coisa importante é que a palavra segurança depende muito do
contexto que ela é utilizada. Por exemplo, é muito comum encontrarmos
esta frase: O Linux é mais seguro que o Windows, por que ele tem
códigos aberto e os bugs são corrigidos mais facilmente. Isto é
verdade, pois não existem "portas do fundo" e incompetência escondida,
em compensação a proteção contra ataques por engenharia reversa, no
Linux, é muito mais difícil do que o Windows.
Na verdade, toda a segurança tem algum ponto de obscuridade. Por isto
que afirmo, NÃO EXISTE SEGURANÇA SEM OBSCURIDADE.
No Caso especifico da urna eletrônica, a coisa é bastante complicada
para software de códigos fechado, porque quem detem o secreto, pode
também ser quem vai atacar o sistema.
Neste caso específico a área de obscuridade tem que ser suficientemente
grande para proteger o sistema e suficientemente pequena para não
permitir (ou dificultar ao máximo) uma fraude no resultado.
Um abraço...
Paulo Gustavo Sampaio Andrade wrote:
Wide Open Source
Elias Levy, SecurityFocus 2000-04-17
Is Open Source really more secure than closed? Elias Levy says
there's
a little security in obscurity.
One of the great rallying cries from the Open Source community is
the
assertion that Open Source Software (OSS) is, by its very nature, less
likely to contain security vulnerabilities, including back doors, than
closed source software. The reality is far more complex and
nuanced.
Advocates derive their dogmatic faith in the implicit security of Open
Source code from the concept of "peer review," a cornerstone of
the scientific process in which published papers and theories are
scrutinized by experts other than the authors. The more peers that
review
the work, the less likely it is that it will contains errors, and the
more likely it is to become accepted.
Open Source apostles believe that releasing the source code for a piece
of software subjects it to the same kind of peer review as a quantum
physics theory published in a scientific journal. Other programmers,
the
theory goes, will review the code for security vulnerabilities, reveal
and fix them, and thus the number of new vulnerabilities introduced and
discovered in the software will decrease over time when compared to
similar closed source software.
It's a nice theory, and in the ideal Open Source world, it would even
be
true. But in the real world, there are a variety of factors that effect
how secure Open Source Software really is.
Sure, the source code is available. But is anyone reading it?
If Open Source were the panacea some think it is, then every security
hole described, fixed and announced to the public would come from
people
analyzing the source code for security vulnerabilities, such as the
folks
at OpenBSD, the Linux Auditing Project, or the developers or users of
the
application.
But there have been plenty of security vulnerabilities in Open Source
Software that were discovered, not by peer review, but by black hats.
Some security holes aren't discovered by the good guys until an
attacker's tools are found on a compromised site, network traffic
captured during an intrusion turns up signs of the exploit, or
knowledge
of the bug finally bubbles up from the underground.
Why is this? When the security company Trusted Information Systems
(TIS)
began making the source code of their Gauntlet firewall available to
their customers many years ago, they believed that their clients would
check for themselves how secure the product was. What they found
instead
was that very few people outside of TIS ever sent in feedback, bug
reports or vulnerabilities. Nobody, it seems, is reading the
source.
The fact is, most open source users run the software, but don't
personally read the code. They just assume that someone else will do
the
auditing for them, and too often, it's the bad guys.
Even if people are reviewing the code, that doesn't mean they're
qualified to do so.
In the scientific world, peer review works because the people doing the
reviewing possess a comparable, or higher, technical caliber and level
of
authority on the subject matter than the author.
It is generally true that the more people reviewing a piece of code,
the
less likely it is the code will have a security flaw. But a single
well-trained reviewer who understands security and what the code is
trying to accomplish will be more effective than a hundred people who
just recently learned how to program.
It is easy to hide vulnerabilities in complex, little understood and
undocumented source code.
Old versions of the Sendmail mail transport agent implemented a DEBUG
SMTP command that allowed the connecting user to specify a set of
commands instead of an email address to receive the message. This was
one
of the vulnerabilities exploited by the notorious Morris Internet
worm.
Sendmail is one of the oldest examples of open source software, yet
this
vulnerability, and many others, lay unfixed a long time. For years
Sendmail was plagued by security problems, because this monolithic
programs was very large, complicated, and little understood but for a
few.
Vulnerabilities can be a lot more subtle than the Sendmail DEBUG
command.
How many people really understand the ins and outs of a kernel based
NFS
server? Are we sure its not leaking file handles in some instances? Ssh
1.2.27 is over seventy-one thousand lines of code (client and server).
Are we sure a subtle flaw does not weakening its key strength to only
40-bits?
There is no strong guarantee that source code and binaries of an
application have any real relationship.
All the benefits of source code peer review are irrelevant if you can
not
be certain that a given binary application is the result of the
reviewed
source code.
Ken Thompson made this very clear during his 1983 Turing Award lecture
to
the ACM, in which he revealed a shocking, and subtle, software
subversion
technique that's still illustrative seventeen years later.
Thompson modified the UNIX C compiler to recognize when the login
program
was being compiled, and to insert a back door in the resulting binary
code such that it would allow him to login as any user using a
"magic" password.
Anyone reviewing the compiler source code could have found the back
door,
except that Thompson then modified the compiler so that whenever it
compiled itself, it would insert both the code that inserts the login
back door, as well as code that modifies the compiler. With this new
binary he removed the modifications he had made and recompiled
again.
He now had a trojaned compiler and clean source code. Anyone using his
compiler to compile either the login program , or the compiler, would
propagate his back doors.
The reason his attack worked is because the compiler has a
bootstrapping
problem. You need a compiler to compile the compiler. You must obtain a
binary copy of the compiler before you can use it to translate the
compiler source code into a binary. There was no guarantee that the
binary compiler you were using was really related to the source code of
the same.
Most applications do not have this bootstrapping problem. But how many
users of open source software compile all of their applications from
source?
A great number of open source users install precompiled software
distributions such as those from RedHat or Debian from CD-ROMs or FTP
sites without thinking twice whether the binary applications have any
real relationship to their source code.
While some of the binaries are cryptographically signed to verify the
identity of the packager, they make no other guarantees. Until the day
comes when a trusted distributor of binary open source software can
issue
a strong cryptographic guarantee that a particular binary is the result
of a given source, any security expectations one may have about the
source can't be transferred to the binary.
Open Source makes it easy for the bad guys to find
vulnerabilities.
Whatever potential Open Source has to make it easy for the good guys to
proactively find security vulnerabilities, also goes to the bad
guys.
It is true that a black hat can find vulnerabilities in a binary-only
application, and that they can attempt to steal the source code to the
application from its closed source. But in the same amount of time they
can do that, they can audit ten different open source applications for
vulnerabilities. A bad guy that can operate a hex editor can probably
manage to grep source code for 'strcpy'.
Security through obscurity is not something you should depend on, but
it
can be an effective deterrent if the attacker can find an easier
target.
So does all this mean Open Source Software is no better than closed
source software when it comes to security vulnerabilities? No. Open
Source Software certainly does have the potential to be more secure
than
its closed source counterpart.
But make no mistake, simply being open source is no guarantee of
security.
Fonte:
http://www.securityfocus.com/news/19
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.12/265 - Release Date: 2/20/2006
|
