|
| seifried |
whoo. ok.
My talk. I was planning something like this: |
| seifried |
I'm going
to cover two, maybe three security problems from a technical perspective |
| seifried |
and then talk
a bit about policy/engineering/yadayada and how it related to all this |
| seifried |
so to start
with a little bit about security |
| seifried |
it's all relative,
proactive, reactive, white lists, black lists, etc. |
| seifried |
to which we
add the problem that everyone has different requirements, and different
amount of money/skill/etc to spend on fixing those problems. |
| seifried |
And unfortunately
we have a rather limited amount of technology to address these problems. |
| seifried |
so the first
issue I was gonna go over is viruses and other malicious code |
| seifried |
something
we've been dealing with as an industry for quite some time now |
| seifried |
unfortunately
it's pretty much impossible to look at a binary and figure out what it
is capable of, even with source code it's not always possible to figure
out exactly what it will |
| seifried |
do |
| seifried |
so we have
a variety of people taking different and overlapping approaches |
| seifried |
one group,
the openbsd team being the best example, but also openwall =), tries for
code correctness |
| seifried |
if the code
is correct it is much harder to abuse in such a way that it does something
hostile, like write to an arbitrary file, or overflow the stack |
| seifried |
so on the
one hand we have things like openbsd, with almost no /tmp file vulnerabilities
in the core OS, because they went through and audited them, and on the
other hand we have numerous linux vendors still issuing /tmp security fixes. |
| seifried |
but openbsd
still has holes and bugs, because code correctness not only relies on proper
symantics and the use of "safe" funcitons like mkstemp() it relies on proper
logic |
| seifried |
the other
problem with code correctness is it requires a huge amount of skill, and
patience. the openbsd team has some very smart people spending years auditing
code |
| seifried |
so then some
people thought "well, code correctness is nice, but let's face it, with
things like SuSE Linxu shipping on a DVD, there is no way we can audit
all this code" |
| seifried |
this leads
to alternative approaches, such as stackguard from immunix, or the openwall
patch by solar |
| seifried |
we all know
at some point we'll have code with a buffer overflow, so instead of trying
to fix every buffer overflow let's make them less dangerous/effective |
| seifried |
in some ways
this is proactive security, because you are potentially preventing problems
we don't even know about yet |
| seifried |
OTOH it is
very reactive because buffer overflows are a well known problem |
| seifried |
unfortunately
however doing things like stackguard and openwall patch are difficult to
do, and require a large amount of effort, and access to very low level
part of the OS |
| seifried |
BUT they can
rpotect us against unknown threats, like a new buffer exploit |
| seifried |
fortunately
now stack protection is available in mopst every OS, in solaris there is
a sysctl switch, in openbsd we have stackghost (for spar conly though),
and for windows we have SecureExe |
| seifried |
however this
is only one limited aspect of malicious code |
| seifried |
another technique
commonly employed is to look for known malicious code, typically with pattern
patching, and then prevent it from executing, or being sent |
| seifried |
this is what
the antivirus industry is based upon |
| seifried |
and it doesn't
work very well, I've receieved 6 viruses via email today so far |
| seifried |
yet we are
constantly told that AV software is the answeer to the virus problem |
| seifried |
because AV
software is largely a reactive defense, even with "heuristics" turned on
it will still fail to detect many viruses and so on |
| seifried |
so we end
up with this constant battle to prevent malicious code from executing,
and in large we are currently losing it |
| seifried |
in any event
I don't think it will be ever winnable, for example is looking up a dns
entry and caching the answer dangerous? |
| seifried |
it is if you
automated software does a cvs update from www.vendor.com, but is sent to
the wrong IP because of a cached answer put there by an attacker |
| seifried |
such examples
are endless |
| seifried |
the next problem
is very simple, but almost never done right |
| seifried |
data deletion |
| seifried |
how many of
you have deleted/wiped data that you really want to be gone, probably all
of us. |
| seifried |
is the data
still there? chances are good it is |
| seifried |
even if you
securely wipe a file when you want to delete it there are still traces: |
| seifried |
if you ever
defragmented, copied or moved the file, a complete or partial copy of it
may be somewhere |
| seifried |
if you ever
viewed or edited the file it may have been loaded into swap space, or written
somewhere as a temporary file |
| seifried |
even if you
try to address this by wiping all free space and your swap file/partition
there are still areas it could behiding, like slack space in other files. |
| seifried |
there is a
HUGE data wiping industry |
| seifried |
and not a
single on of there products that I tested wipes data effectively, and most
of them were aware of this |
| seifried |
so, we can't
trust files to be wiped, how can we proactively solve the problem? |
| seifried |
encryption
is one answer, store the data such that if you don't delete it properly
the attacker will still not be able to view it (in theory) |
| seifried |
ignoring problems
like temporary files, copies, swap space and so on we have just created
a huge set of new problems |
| seifried |
to encrypt/decrypt
you need keys, keys that have to be _securely_ stored |
| seifried |
and the software
that encrypts/decrypts has to be secure, and if you look for security bulletins
on these products you will find them |
| seifried |
so, two relatively
simple problems, that are still problems, despite a decade or two of research
and applied technology |
| seifried |
starting at
the technological end we have "simple" issues like the turing halt problem |
| seifried |
it's simply
impossible to figure out what software is capable of. and if this software
runs as root or is setuid... heaven help us |
| seifried |
so we try
to restrict what it can do. file permissions are a good example. enforced
by the kernel of the os (hopefully) it prevents software from writing/access
files it shouldn't |
| seifried |
this has a
tendancy to fail however since good file permissions are hard |
| seifried |
as solar points
out they try to restrict them in openwall to prevent a small compromise
from becoming a big one |
| seifried |
and in order
to do these thigns they have had to spend some serious effort modifying
tools and permissions |
| seifried |
moving further
along we have the problem of scale and usability |
| seifried |
computers
are to most people first and foremost a tool that fullfills some functions |
| seifried |
that is the
primary issue |
| seifried |
not whether
it is secure or not |
| seifried |
when does
software ship? when it works. not when it is secure. |
| seifried |
this however
is not completely bad. I am sitting here in win2k server. I _know_ for
a fact there are remote and local admin exploits in it |
| seifried |
am I running
AV software? no |
| * seifried likes to live on the
edge hey? =) |
| seifried |
with judicious
use of firewalling, ehavily restrictive settings, and so on I'm able to
secure this system |
| seifried |
ah right ok |
| seifried |
well as the
ongoing discussion in #qc prooves: it's complicated. |
| seifried |
even something
that should be simple like wiping a file |
| seifried |
is incredibly
difficult, even on a local system |
| seifried |
every solution
breeds new problems |
| seifried |
but this is
ok, because ultimately security is risk management, and not absolute |
| seifried |
so hopefully
if I can get one thing to you today it is that security is not every going
to be done, you will never achieve a "secure" state. |
| seifried |
but you can
achieve a state that mitigates enough risk to make the cost of security
problems affordable. |
| seifried |
and still
leave your systems usable for work |
| seifried |
hmm. I think
thwre is more interest in arguing about file deletion/encryption, questions
anyone? |
| seifried |
so any questions? |
| *** sarnold sets mode: -m |
| sarnold |
clap clap
clap clap clap |
| sarnold |
clap clap
clap clap clap |
| sarnold |
clap clap
clap clap clap |
| sarnold |
clap clap
clap clap clap |
| jose_n |
clap clap
clap clap clap |
| jose_n |
clap clap
clap clap clap |
| jose_n |
clap clap
clap clap clap |
| sarnold |
thanks to
kurt seifried, solar designer, and 3APA3A for their presentations today
:) |
| MJesus |
thanks to
traslators ! |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| sarnold |
I think we
had a lot of fun :) |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| viZard |
PLAS PLAS
PLAS PLAS PLAS PLAS PLA PLAS |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| sarnold |
there is still
good conversation going on in #qc and #owl |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
clap clap
clap clap clap clap clap clap clap clap |
| MJesus |
thank you
! |
| sarnold |
remember,
we extended the conference by one more day :) |
| sarnold |
doctor jose
nazario will be giving _two_ presentations tomorrow -- one an introduction
to openbsd, the other about his source-code vulnerability scanner |
| sarnold |
and, KF will
be teaching us all about format string vulnerabilities :) |
| MJesus |
thaks sarnold
!! |
| MJesus |
thaks sarnold
!! |
| seifried |
heh |
| seifried |
which scanner
is that? |
| jose_n |
thank you
sarnold, MJesus, viZard, solar, nergel, kurt! |
| bighawk |
KF, isn't
that the guy who asked for help for string-enumeration? :) |
| * seifried thought he kept track
of all of them..... |
| jose_n |
kurt: czech,
available for view at pedantic.sf.net |
| viZard |
seifried:
sorry on website it says you are from USA :X |
| seifried |
heh |
| *** phaula has quit IRC |
| seifried |
well,I work
for .us companies mostly |
| viZard |
where do you
live at? |
| seifried |
int he last
4 years I've done 7 hours of work for canadian companies |
| seifried |
canada |
