<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">

<channel>
<title>Open source release takes Linux rootkits mainstream in All Things Unix</title>
<link>http://www.dslreports.com/forum/r21063115</link>
<description></description>
<language>en</language>
<pubDate>Wed, 11 Nov 2009 03:33:00 EDT</pubDate>
<lastBuildDate>Wed, 11 Nov 2009 03:33:00 EDT</lastBuildDate>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21077752</link>
<description><![CDATA[<A HREF="/useremail/u/782124"><b>BeesTea</b></A> : This is defendable, even from root, by removing the kernel module loader support from the kernel.  Presumably this can be easily modified to allow insertion directly into kmem as well.  For that, you'd need stricter access control on the kmem device.  Using something like SELinux, GRSecurity, or RSBAC could allow you to protect yourself from that attack vector as well.<br><small>--<br>Overpower, overcome.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21077752</guid>
<pubDate>Mon, 08 Sep 2008 17:53:25 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21077217</link>
<description><![CDATA[<A HREF="/useremail/u/715380"><b>Maxo</b></A> : <div class="bquote"><small>said by  SUMware <A HREF="/useremail/u/634007"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>It would also somehow need to be installed by root.</div>Anything is possible once you've given untrusted code root access, so I don't see myself fearing much.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21077217</guid>
<pubDate>Mon, 08 Sep 2008 16:06:51 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21072547</link>
<description><![CDATA[<A HREF="/useremail/u/1464133"><b>a333</b></A> : <div class="bquote"><small>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>I'm pretty sure that when Windows gets attacked, kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.<br> </div>Oh, I doubt my post was "vacuous" or irrevalent in any way. As per the above quote, you stated that you're sure that Windows developers would improve and secure their kernel in the event of new exploits. If that were the case, Windows would become more secure with each release/patch it released . However, we all have seen that security on Windows isn't something to be particularly proud about. That clearly raises questions as to Microsoft's priorities...<br>Thus, my post was quite on topic, as far as replying to yours was concerned. <br>    ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21072547</guid>
<pubDate>Sun, 07 Sep 2008 18:52:29 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21072374</link>
<description><![CDATA[<A HREF="/useremail/u/168864"><b>sporkme</b></A> : <div class="bquote"><small>said by  SUMware <A HREF="/useremail/u/634007"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>o Get a remote MOSDEF Node (via hidden userland-backdoor)<br> </div>What does he have to do with all this?<br><small>--<br>with every mistake we must surely be learning</small><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#FFFFFF nwrap COLSPAN=2 WIDTH=66%><A HREF="/speak/slideshow/21072374?c=1347492&ret=L2ZvcnVtL3IyMTA2MzExNS54bWw%3D"><IMG TITLE="8038 bytes" BORDER=0 WIDTH=252 HEIGHT=252 SRC="/r0/download/1347492~e27e5979d4afa6994399996fdb0fa559/MosDef.jpg"></A><br>I've got mad nodes...</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21072374</guid>
<pubDate>Sun, 07 Sep 2008 18:22:27 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21071286</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote"><small>said by  a333 <A HREF="/useremail/u/1464133"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>If what you said actually played out in the real world, Windows wouldn't have created a multibillion-dollar antivirus software industry. By your logic, each release of Windows would be significantly safer, and by now, the need for AV S/W would be close to nil. Also, malware devs/ script kiddies would give up writing viruses for Windows, and move on to an easier platform... <br> </div>Please read. <br><br>I'm commenting on what was actually written, which was solely about whether kernel developers and security experts will look at the kernel code.<br><br>Amongst the things not mentioned, and therefore not commented-on by me, were:<br><br>1)  How many people<br><br>2)  How skilled they might be<br><br>3)  Whether the results would be better or worse<br><br>4)  Which kernel is 'better'<br><br>5)  Which development methodology is better<br><br>6)  Anti-virus software in general<br><br>7)  Whether A-V software is useful or snake oil<br><br>8)  Whether script kiddies target 'easy' or 'ubiquitous' targets<br><br>9)  Whether  nil <A HREF="/useremail/u/251107"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> is close to the need for A-V<br><br>You may have opinions on all these things, and so might I, but they were not mentioned in  Brano <A HREF="/useremail/u/649954"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>'s post and therefore not relevant to my reply to that post.  The point under discussion is whether kernel developers and security experts look at kernel code after hearing about a kernel rootkit affecting that code.<br><br>If you'd care to discuss what I actually wrote, we can carry on. Although this is certainly a tedious elaboration on what was essentially a flippant post by me, whose gist was intended to be 'you really ought to read what you wrote, because it is vacuous'. ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21071286</guid>
<pubDate>Sun, 07 Sep 2008 14:15:29 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21071171</link>
<description><![CDATA[<A HREF="/useremail/u/1464133"><b>a333</b></A> : If what you said actually played out in the real world, Windows wouldn't have created a multibillion-dollar antivirus software industry. By your logic, each release of Windows would be significantly safer, and by now, the need for AV S/W would be close to nil. Also, malware devs/ script kiddies would give up writing viruses for Windows, and move on to an easier platform... ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21071171</guid>
<pubDate>Sun, 07 Sep 2008 13:52:15 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21069693</link>
<description><![CDATA[<A HREF="/useremail/u/1425637"><b>Feral Kid</b></A> : It sounds all scary and everything but how would I actually get this thing to infect me?<br><br>p.s. it's just a general reply, not specifically to SUMware (sorry first post)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21069693</guid>
<pubDate>Sun, 07 Sep 2008 04:22:05 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21069008</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : What has that got to do with anything? The subject was whether kernel programmers and security experts look at the affected kernel software after rootkits are published.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21069008</guid>
<pubDate>Sat, 06 Sep 2008 23:20:13 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21068950</link>
<description><![CDATA[<A HREF="/useremail/u/1464133"><b>a333</b></A> : I'm quite sure that's why Windows has helped created a billion-dollar antivirus software market, and a wide array of exploits that grow by the 100's as we speak...]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21068950</guid>
<pubDate>Sat, 06 Sep 2008 23:07:36 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21068051</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote"><small>said by  Brano <A HREF="/useremail/u/649954"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>Not to undermine the seriousness of this, but since it's open source one can be sure that kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.<br>Open source works both ways ;)<br> </div>I'm pretty sure that when Windows gets attacked, kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21068051</guid>
<pubDate>Sat, 06 Sep 2008 12:40:06 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21068032</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : The 'new thing' in this kit is used of the hardware debug registers.<br><br>You're familiar with attacks such as hooking the system call table?  This has heretofore been done by planting instructions in said table, to revector control to where we want it to go.<br><br>That's how we used to do software debugging. <br><br>However, a better approach (less fussing around rewriting pieces of the code under test) relies on hardware support. Instead of modifying the instruction at address N, for example, you set up debug registers to say 'issue a trap when you are about to execute the instruction at address N'.  <br><br>You can also do things like 'trap when any instruction tries to read or write address N', which is a lot more convenient than doing the same thing by software manipulation of page tables.<br><br>OK, so here's some guesswork on my part about what this new approach does:<br><br>It substitutes 'patching dispatch tables' with 'setting up debug registers to achieve the same thing'. This is a good idea, since it's less invasive, and presumably therefore less easy to detect.<br><br>I imagine that the rest of it, while fearsome, is 'standard rootkit stuff'. You could do that with any method that allows you to grab control at suitably-chosen points in execution. <br><br>One can infer all this from, basically, this single paragraph:<br><br>  <blockquote><small>quote:</small><hr>DR features a reference implementation of a IA32 debug register based rootkit hooking engine. It does not modify IDT or syscall_table at all but still provides transparent syscall hooking on IA32 Linux 2.6.<hr></blockquote><br><br>Lest you misunderstand my first post, I was criticizing the reporter's use of garbage phrases like 'burrowing deep inside the processor'.  This is not rocket science. It is (AFAIK) using documented processor facilities in the manner in which they were intended to be used. The new insight is that debugging and call-trapping for rootkits are the same thing.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21068032</guid>
<pubDate>Sat, 06 Sep 2008 12:33:57 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21067387</link>
<description><![CDATA[<A HREF="/useremail/u/634007"><b>SUMware</b></A> : <div class="bquote"><small>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>  :</small><br><br><div class="bquote">It's notable because it cloaks itself by burrowing deep inside a server's processor </div>Wow! Burrowing deep inside a server's processor!  Sounds really hardcore. I wonder what they mean?<br><br><div class="bquote">and availing itself of debugging mechanisms available in Intel's chip architecture.</div>Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!<br> </div>Excerpted from: &raquo;<A HREF="http://seclists.org/dailydave/2008/q3/0215.html" >seclists.org/dailydave/2008/q3/0215.html</A><br><br>From: Bas Alberts <br>Date: Wed, 03 Sep 2008 16:32:54 -0400<br><br>Currently the rootkit can:<br><br>o Hide processes<br>o Hide network sockets<br>o Hide files<br>o Get a remote MOSDEF Node (via hidden userland-backdoor)<br><br>The major benefit of the DR rootkit is that all this happens transparently to the end user. The children of a hidden process are also automatically hidden. The sockets a hidden process creates are also hidden. But if you are a hidden process, you can see hidden resources. This makes the DR rootkit nicely manageable.<br><br>DR loads via insmod - we've tested the rootkit on a number of Linux distributions including CentOS and Ubuntu. <br><br>About<br>=====<br><br>DR features a reference implementation of a IA32 debug register based rootkit hooking engine. It does not modify IDT or syscall_table at all but still provides transparent syscall hooking on IA32 Linux 2.6.<br><br>Features<br>========<br><br>SystemCall hooking without modifying IDT, or syscall_table, at all. Not even for a milisecond(tm). Using hardware execute and read breakpoints.<br><br>Details<br>=======<br><br>DR places a hardware breakpoint on the syscall handler, and the resulting trap places a memory watch on the syscall_table entry for the __NR_syscall of the intercepted syscall. It does this for both INT 0x80 and sysenter based system calls.<br><br>When the memory watch for the syscall_table entry kicks in, the trap handler then redirects execution for that syscall to a syscall hook.<br><br>Example Flow<br>============<br><br>Execute global breakpoint on syscall handler in dr0, syscall is called, breakpoint kicks in. Modified do_debug handler places global read watch on syscall_table[__NR_syscall]. When syscall is called, memory access breakpoint kicks in. Modified do_debug handler places function pointer to hooked syscall in task regs eip. Execution is redirected to hooked syscall. Repeat.<br><br>[ 864.447800] ******* LOADING IA32 DR HOOKING ENGINE *******<br>[ 864.447868] *** loader: handler for INT 128: C0104210<br>[ 864.447923] *** loader: syscall_table: C02FC540<br>[ 864.447934] *** loader: syscall_call call *table(,eax,4): C010424B<br>[ 864.447952] *** loader: handler for INT 1: C02F4360<br>[ 864.448085] *** loader: INT 1 handler patched to use __my_do_debug<br>[ 864.448165] *** loader: initialized hook_table<br>[ 864.448199] *** loader: systenter_entry call *table(,eax,4): C01041CB<br>[ 871.592214] *** dr0/dr1 trap: setting read watch on syscall_NR of 220 at C02FC8B0<br>[ 871.598191] *** got dr2 trap (syscall_table watch)<br>[ 871.598723] *** hooked __NR_220 to E0AC7350<br><br>Using the memory watch approach, one does not have to modify IDT or syscall_table ever. This is an original approach, but considering we _are_ the debugger .. one could dream up a million other viable and fruitful solutions to non-memory modifying DR rootkits.<br><br>Limitations<br>===========<br><br>This is a reference implementation. A lot more can be done to actually be hidden. Production code will include kmalloc based non-LKM code handling. Full Global Detect debug register access detection support, and additional memory watching for the debug ENTRY call offset patch.<br><br>Additional testing is required to check for scheduler issues and other racy problems. This reference implementation is intended as a case study into the general rootkit approach now that the cat is out of the bag.<br><br>The provided example hooks serve as a basic example rootkit known to suffer the following limitations:<br><br>Detection<br>=========<br><br>In it's current form there is no prevention of someone else accessing the debug registers. This could be easily added with GD access flag control, however this is left as an exercise to the reader.<br><br>Furthermore this module behaves like a normal LKM in that is has symbols and is resident in memory like a normal LKM. This can be bypassed by porting the module init to a kmalloc based loading logic. To be added in v0.2.<br><br>- - Detection via module based symbols<br>- - Detection via granted access to hardware debug registers<br>- - Detection via timing logic<br>- - Detection via open("/proc/hiddenpid/stat"); success<br><br>Adding/Changing hooks<br>=====================<br><br>All hooks are defined in hooktable.h. A good example template is the hook_example_exit function. Once a hook is added to the global hook table, it will be automagically used by the hooking engine.<br><br>     10 asmlinkage static void hook_example_exit(int status);<br><br>    ...<br><br>    149 asmlinkage /* required: args passed on stack to syscall */<br>    150 static void hook_example_exit(int status)<br>    151 {<br>    152 /* standard hook prologue */<br>    153 asmlinkage int (*orig_exit)(int status);<br>    154 void **sys_p = (void **)sys_table_global;<br>    155 orig_exit = (int (*)())sys_p[__NR_exit];<br><br>    ...<br><br>    167 else<br>    168 return orig_exit(status);<br>    169 }<br><br>You then initialize this function in the global hook_table as such:<br>    121 hook_table[__NR_exit] = (void *)hook_example_exit;<br><br>The hooking engine was designed to be very friendly and open to modification/extension. It was designed to provide a more current hooking engine for existing sycall_table based rootkit logic. All rootkit specific logic lives in hooktable.h.<br><br>Todo<br>====<br><br>- - move to kmalloc based init loader, -EINVAL return<br>- - improve hooks to do proper '/proc' and getdents handling<br>- - move /proc handling to inode based checks<br>- - instruction emulation for outside debug register access GD stylee<br><br>Credits<br>=======<br><br>The debug register based hooking engine was written by Bas Alberts, all additional hooks contained in hooktable.h, besides the example hook_exit were written by Daniel Palacio.<br>**************<br>Edit:<br>Pierre Falda posted additional comments <A HREF="http://seclists.org/dailydave/2008/q3/0216.html">here</a>.<br>Joanna Rutkowska posted additional comments <A HREF="http://seclists.org/dailydave/2008/q3/0221.html">here</a>.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21067387</guid>
<pubDate>Sat, 06 Sep 2008 09:43:22 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21067293</link>
<description><![CDATA[<A HREF="/useremail/u/649954"><b>Brano</b></A> : Not to undermine the seriousness of this, but since it's open source one can be sure that kernel developers and other security experts will analyze the code and will try to make future kernel more resistant against such rootkits.<br>Open source works both ways ;)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21067293</guid>
<pubDate>Sat, 06 Sep 2008 09:12:57 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21066881</link>
<description><![CDATA[<A HREF="/useremail/u/1578887"><b>KodiacZiller</b></A> : There's nothing to be afraid of as an average desktop user.  As I'm sure you all know, all rootkits do, by definition, is allow someone to cover their tracks once the machine is ALREADY cracked.  It isn't like you can accidentally download one (a la trojans on Windows).  And even if you did, it wouldn't execute unless you explicitly give it permission.<br><br>Turn off unneeded services, update often, and run a firewall, and the chances of a desktop user being cracked are next to nil.  Security 101 is all you need.<br><br>Now "high value" servers on the other hand...  They might have a problem with this, but I doubt it will be epidemic.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21066881</guid>
<pubDate>Sat, 06 Sep 2008 04:55:13 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21066347</link>
<description><![CDATA[<A HREF="/useremail/u/878241"><b>JohnInSJ</b></A> : <div class="bquote"><small>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br><div class="bquote">It's notable because it cloaks itself by burrowing deep inside a server's processor </div>Wow! Burrowing deep inside a server's processor!  Sounds really hardcore. I wonder what they mean?<br><br><div class="bquote">and availing itself of debugging mechanisms available in Intel's chip architecture.</div>Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!<br> </div>LOL... Yeah. It uses machine code and everything. Be afraid.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21066347</guid>
<pubDate>Sat, 06 Sep 2008 00:14:23 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21066273</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote"><small>said by happylurk :</small><br><br>Ten again on rereading I noted that it seems to be specific to Intel architecture.  Does that mean I've bought myself some extra time by running an All-AMD shop?<br> </div>If the AMD doesn't have equivalent debug registers, it's useless for OS development. Therefore we can conclude AMD has debug registers.<br> <br>I think they've been in the architecture since the 386, so AMD has had plenty of time to copy them!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21066273</guid>
<pubDate>Fri, 05 Sep 2008 23:51:05 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21066234</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote">It's notable because it cloaks itself by burrowing deep inside a server's processor </div>Wow! Burrowing deep inside a server's processor!  Sounds really hardcore. I wonder what they mean?<br><br><div class="bquote">and availing itself of debugging mechanisms available in Intel's chip architecture.</div>Oh, you mean it 'executes instructions' and 'writes to registers'. Wow indeed!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21066234</guid>
<pubDate>Fri, 05 Sep 2008 23:40:21 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21065378</link>
<description><![CDATA[<A HREF="/useremail/u/782124"><b>BeesTea</b></A> : <div class="bquote"><small>said by  TSI Gabe <A HREF="/useremail/u/1427767"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> :</small><br><br>Something tells me that a lot of Rootkits will derive from this one and probably very soon...<br> </div>I believe there's a few in the wild behaving this way today.  This just happens to be a company releasing it rather than a miscreant.  Unless I'm missing something, the part that's new is the license.  There's even been "commercially supported" rootkits in the past.<br><br>Ugly,  but not worse than where we were I suspect.<br><small>--<br>Overpower, overcome.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21065378</guid>
<pubDate>Fri, 05 Sep 2008 20:53:50 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21065226</link>
<description><![CDATA[<A HREF="/useremail/u/1427767"><b>TSI Gabe</b></A> : This just shows that tools like chkrootkit can be useless if you know what you are doing. While it is a good thing that they released this under GPL and that I'm sure that they will add some sort of detection in the tool for this technique. <br><br>Something tells me that a lot of Rootkits will derive from this one and probably very soon...<br><small>--<br>TSI Gabe - TekSavvy Solutions Inc.</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21065226</guid>
<pubDate>Fri, 05 Sep 2008 20:21:46 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063622</link>
<description><![CDATA[<A HREF="/useremail/u/634007"><b>SUMware</b></A> : <A HREF="http://blogs.zdnet.com/open-source/?p=2864">An open source rootkit kit</a> September 5th, 2008<br> <blockquote><small>said by Dana Blankenhorn :</small><hr>The Register is convinced that former NSA programmer Dave Aitel has gone over to the dark side by making his DR Rootkit open source under GPL 2.<br><br>While it&#146;s true that the program can make rootkits, I don&#146;t see it as a net loss for Linux security.<br><br>I think it may be more of a honeypot.<hr></blockquote>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063622</guid>
<pubDate>Fri, 05 Sep 2008 15:51:51 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063373</link>
<description><![CDATA[<A HREF="/useremail/u/634007"><b>SUMware</b></A> : Yep, not a "feel-good"...<br>More info: &raquo;<A HREF="http://seclists.org/dailydave/2008/q3/0215.html" >seclists.org/dailydave/2008/q3/0215.html</A><br><br>Edit: At this time I could find no information that this would affect any other product except Intel. It would also somehow need to be installed by root.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063373</guid>
<pubDate>Fri, 05 Sep 2008 15:16:08 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063265</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Ten again on rereading I noted that it seems to be specific to Intel architecture.  Does that mean I've bought myself some extra time by running an All-AMD shop?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063265</guid>
<pubDate>Fri, 05 Sep 2008 14:55:37 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063234</link>
<description><![CDATA[<A HREF="/useremail/u/165405"><b>drjim</b></A> : You're not the only one.....]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063234</guid>
<pubDate>Fri, 05 Sep 2008 14:50:07 EDT</pubDate>
</item>

<item>
<title>Re: Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063206</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : Why did I just feel my sphincter clench up when I read that? :p]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063206</guid>
<pubDate>Fri, 05 Sep 2008 14:45:02 EDT</pubDate>
</item>

<item>
<title>Open source release takes Linux rootkits mainstream</title>
<link>http://www.dslreports.com/forum/remark,21063115</link>
<description><![CDATA[<A HREF="/useremail/u/634007"><b>SUMware</b></A> : From <A HREF="http://www.theregister.co.uk/2008/09/04/linux_rootkit_released/">The Register</a><br>4th September 2008 - <blockquote><small>quote:</small><hr>The art of burying invisible malware deep inside a Linux machine is about to go mainstream, thanks to a new open-source rootkit released Thursday by Immunity Inc., a firm that supplies tools for penetration testers.<br><br>When implemented, Immunity's DR, or Debug Register, makes backdoors and other types of malware extremely difficult to detect or eradicate. It's notable because it cloaks itself by burrowing deep inside a server's processor and availing itself of debugging mechanisms available in Intel's chip architecture. The rootkit, in other words, mimics a kernel debugger.<br><br>By exploiting a CPU's native ability to generate interrupts, DR escapes some of the pitfalls that have visited more traditional types of rootkits, which modify an operating system's system call table. That's of increasing importance as more and more Linux distributions make it harder to make changes to the syscall table and rootkit detection programs such as chkrootkit and rkhunter actively check for such modifications.<br><br>Over the past few years, a growing body of malware has incorporated rootkits, making detection much harder. Until now, the benefit of using a rootkit was counterbalanced by the difficulty of building one. DR, which is <A HREF="http://www.immunityinc.com/resources-freesoftware.shtml">available here</a> under version 2 of the general public license, will make it profoundly easier.<br><br>"In the old days, to attack a computer, you needed to 1) find a bug, 2) write an exploit, 3) run the exploit 4) hide yourself," Charlie Miller, principal security analyst for Independent Security Evaluators, said in an email. "The gap between a script kiddie and a hacker just got a little smaller."<br><br>While DR simplifies the task of cloaking nasty malware on Linux boxes, it doesn't support symmetric multiprocessing or actively hide itself at the kernel level. The good news is that those are shortcomings that limit the rootkit's functionality and make it easier to detect.<br><br>The bad news: these features could be added with about a week's worth of development time. Indeed, Immunity is offering commercial support for DR as part of its Canvas toolkit<hr></blockquote>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,21063115</guid>
<pubDate>Fri, 05 Sep 2008 14:31:01 EDT</pubDate>
</item>

</channel>
</rss>
