Hi all. I'm new to the list, but I've been GIMPING for just over two years.
I'd been thinking about possible security risks myself just before I joined
the list, so it's a bit of a coincidence that this was the first thread I
read.
>From: Brian J. Beesley
>Subject: Re: Mersenne: Security of prime95 + electricity costs.
>Date: Fri, 09 Mar 2001 14:25:07 -0800
>
>-----------------------------------------------------------------------------
---
>
>On 9 Mar 2001, at 15:35, Joshua Zelinsky wrote:
>
>> 1. How will Prime95 affect security? I don't think there would be any major
>> problems created, but the readme doesn't discuss this much and this isn't
my
>> area of expertise. Any thoughts?
>
>The _only_ security risk to the user associated with Prime95 is the
>same risk associated with downloading and executing _any_ program.
>Possibly we should be providing MD5 checksums to go with the binaries
>so that they can be checked for non-interference.
>
>The network communications between the server and client pose no risk
>as there is no instruction payload. All the code you need is in the
>binary executable and the DLLs supplied.
That doesn't necessarily follow. The 'classic' buffer overrun exploit is
where an attacker deliberately overruns a fixed length buffer, clobbering any
adjacent data and - if the buffer is declared as a local (stack) variable -
the return address of the last subroutine call. In that case, the attacker
can cause the program to 'return' to an arbitrary place within the program's
virtual memory including the clobbered stack, allowing him to execute his own
payload. Result: Potentially the attacker can gain all the privileges of the
attacked program. The fact that the /intended/ messages contain no
instruction payload is irrelevant.
Whether prime95 or any of the other clients (or even the server) has such a
vulnerability I don't know. Has anyone actually checked? If it does, then to
exploit it the attacker would either have to masquerade as the server - rather
difficult to do if communication is always initiated by the client. He would
have to monitor the network (LANs being more vulnerable than the Internet at
large) for server bound packets - or he could crack and compromise the server
itself. This would give him the capability to attack any (or every) client.
A firewall can not protect against this, since client-server communications
are permitted. I would suggest anyone running an Internet client (of any
kind, including browsers) on a *nix system give it it's own UID/GID, and
ensure that no file or directory on the system is world-readable unless it
needs to be. Even this may not be foolproof, since there may be other
vulnerabilities in any given system that could be exploited by the attacker
once he has got a toehold.
I don't know the security models for WIN98/NT/ME But I expect something
similar would be possible. WIN95 and earlier can't be secured in this way.
I would also suggest - if it hasn't already been done - that the message
handling routines in the client do as much sanity checking as possible, and
abort the program /before/ returning if anything untoward is found.
Regards
Daran Gill
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
