lkml.org 
[lkml]   [1999]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: malware defense
Horst von Brand wrote:
>
> "Robert G. Brown" <rgb@phy.duke.edu> said:
>
> [...]
>
> > The problem is that >>any<< daemon, running basically outside of the
> > kernel as an ordinary task, just continues a vicious cycle of:
> >
> > a: (bad guys) develop clever(er) exploit
> > (good guys) develop clever(er) counterexploit
> > goto a:
> >
> > How do you protect against corruption/replacement of the daemon software
> > that checks the images? Quid custode custodes? Right now, "rootkit"
> > packages come with pre-scripted cracking tools that, when they succeed,
> > encapsulate the cracker invisibly, blinding the tools required to "see"
> > them. This just adds another tool or layer of tools they have to
> > replace. After all, how are you to know if the daemon you started is
> > truly the daemon that is currently running if the cracker controls the
> > daemon, ps, ls, and all that? They'll all lie to you, just like they do
> > now for many rootkits.
>
> Then you need a way to certify what is on your system, probably off-line: A
> rescue-diskette style freestanding system that keeps the tools to check the
> files on the system, and perhaps also a database of cryptographic hashes
> for key system pieces.
>
> The ideas you seem to advocate are called "security through obscurity" in
> crypto circles, where they have been thoroughly discredited. What is needed
> is publically scrutinized, easy to use and unintrusive systems that rely on
> secure mechanisms (i.e., crypto keys, secure hashes) to verify integrity.
> If the source is open, everybody will look it over, and flaws will be found
> and fixed quickly. If the source is closed, flaws will be discovered a bit
> slower by the wrong people, and never fixed.
>
> Packages today are distributed with MD5 hashes, and signed with PGP/GPG, so
> it is _very_ hard to troyan a package and getting away with it for any
> amount of time.

I was part of the team that caught the cracker that broke into the
central GNU archive server (among other sites). He didn't stop there,
but just bounced on, leaving a backdoor for other recipe-book hackers
using the same toolset. (We were decoding the packets from a university
server he'd hacked into, and logging, while reconstructing what he was
seeing in another window. It wasn't perfect, but it was good enough)

When he cracked into the GNU site..._THAT_ was when we all went pale,
and turned to the feds and said "Get in there and grab this guy now." We
all knew how many times we'd downloaded and compiled GNU tools,
expecting the source to be pristine. The feds had him in custody 15
minutes later.

We then started going back through the logs and emailing site admins
telling them what had happened and which files had been affected to
leave the backdoors. It took us the rest of the night to get the
warnings off. Many didn't believe us. I have no idea if the GNU folks
responded....Other people handled the replies, while I went off and got
drunk.

I still think about the implications. Just a small hack in one version
of gcc somewhere... Yeesh.

Although this was about 3.5 years ago now, I'm not sure if the guys from
wustl ever got thanked for warning us about the odd traffic coming from
the university servers. My generally directed thankfulness to them all,
whoever they are.

D

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.069 / U:2.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site