<br><font size=2 face="sans-serif">Open up /dev/mem /dev/kmem. I
am sure that newer *Nix would have newer safeguards, my experience is with
old *Nix. But in the past, if you have r/w access to kernel memory,
you can easily compromise a system. </font>
<br>
<br><font size=2 face="sans-serif">johnl</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Chris Hilton <chris129@cs.iastate.edu></b>
</font>
<br><font size=1 face="sans-serif">Sent by: cialug-bounces@cialug.org</font>
<p><font size=1 face="sans-serif">01/05/2006 02:04 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Central Iowa Linux Users Group <cialug@cialug.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Central Iowa Linux Users
Group <cialug@cialug.org></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [Cialug] Nix Shared Code
Injection</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>How could you have read write access to another process's
memory without it <br>
explicitly giving it to you via shared memory?<br>
<br>
On Thursday 05 January 2006 13:31, John.Lengeling@radisys.com wrote:<br>
> Thinking off the top of my head...<br>
><br>
> Under UNIX, there isn't an API call (that I know of...) which would
do the<br>
> same thing as Windows, but there are several ways of injecting code
or<br>
> getting a process to run arbitrary code:<br>
><br>
> 1. R/W access to the Kernel memory - If you have r/w access, you can<br>
> access any part of the kernel or any process's memory. Plus
the ghost is<br>
> up for anything else since you can easily get root access.<br>
> 2. R/W access to the Process memory - If you have r/w access,
you can<br>
> change code/data in the process's memory space. And if the process
has<br>
> root permissions, then even better.<br>
> 3. Buffer overflows - If you can overflow a buffer, you can force
the<br>
> process to execute arbitrary code. See information on Morris
Worm.<br>
> 4. Intercepting exec/forks of new processes - Badly written
exec/fork<br>
> code can be compromised by executing some other program.<br>
><br>
><br>
><br>
><br>
> Chris Hilton <chris129@cs.iastate.edu><br>
> Sent by: cialug-bounces@cialug.org<br>
> 01/05/2006 01:05 PM<br>
> Please respond to<br>
> Central Iowa Linux Users Group <cialug@cialug.org><br>
><br>
><br>
> To<br>
> Central Iowa Linux Users Group <cialug@cialug.org>, amesfug@amesfug.org<br>
> cc<br>
><br>
> Subject<br>
> [Cialug] Nix Shared Code Injection<br>
><br>
><br>
><br>
><br>
><br>
><br>
> I've got a theoretical question. It's come to my attention that
the way<br>
> in<br>
> which a lot of spyware works is through some API's in Windows (apparently<br>
> written for debuggers) by injecting a dll into another running
process.<br>
> The<br>
> standard process permissions apply, but you can inject from say bob.exe<br>
> into<br>
> iexplorer.exe.<br>
> My question is about Nix though. Does anyone know if this can
be done on<br>
> Nix?<br>
><br>
> I've looked into Sys V IPC for shared memory and mmap and neither
look<br>
> like<br>
> you could involuntarily to anything to another processes memory space<br>
> (it'd<br>
> have to open the same IPC location if I read correctly).<br>
> I also looked at processes look like under gdb, and not under it:
They<br>
> look<br>
> exactly the same. I compared /proc/`pidof procName`/maps to
compare.<br>
><br>
> I'm not finding anything to suggest a way to do this, at least not
a way<br>
> that<br>
> wouldn't be against what the documentation says. Does anyone
know more<br>
> about<br>
> this? It's peaked my curiousity.<br>
><br>
><br>
> On a side note. This is why zonealarm doesn't stop nearly as
much spyware<br>
> as<br>
> it used to. Since spyware can hitch its own dll on iexplorer
and do its<br>
> sends from there it looks like iexplorer is connecting to the net;
and no<br>
> one<br>
> but a firefox user, who doesn't run updates, would refuse that ;).<br>
<br>
-- <br>
"The only winning move is not to play."<br>
_______________________________________________<br>
Cialug mailing list<br>
Cialug@cialug.org<br>
http://cialug.org/mailman/listinfo/cialug<br>
</tt></font>
<br>