Slashdot Mirror


New Approach To Malware Modifies Linux Kernel

Hugh Pickens writes "Professor Avishai Wool has unveiled a program to watch for malware on servers with a modification to the Linux kernel. 'We modified the kernel in the system's operating system so that it monitors and tracks the behavior of the programs installed on it,' says Wool. Essentially, Wool says, his software team has built a model that predicts how software running on a server should work (pdf). If the kernel senses abnormal activity, it stops the program from working before malicious actions occur. 'When we see a deviation, we know for sure there's something bad going on,' Wool explains. Wool cites problems with costly anti-virus protection. 'Our methods are much more efficient and don't chew up the computer's resources.'"

170 comments

  1. Help! by i_liek_turtles · · Score: 5, Funny

    It's stopped me from running Vista in a VM...

    1. Re:Help! by Anonymous Coward · · Score: 4, Funny

      How is this off-topic? The mods must have been infected!

    2. Re:Help! by Anonymous Coward · · Score: 5, Funny

      That's nothing. I ran it in a virtual machine on Vista. It broke out, took over the machine, and put vista in a vm.

    3. Re:Help! by supernova_hq · · Score: 1

      Adds a whole new meaning to the term jailbreak...

  2. premise to shutdown by thatchman1 · · Score: 5, Interesting

    Is this not the very premise that caused the Amazon cloud shutdown? A failure to communicate back proper activity illogically deduced that there was an improper activity?

    1. Re:premise to shutdown by Anonymous Coward · · Score: 0

      New Malware e-mails you and all your friends, says "Lose Weight you FATASS!!" in the subject of the e-mail and the body contains a JPG attachment of Rosie O'donnell that says "Do you really want to resemble THIS?!" This has greatly increased the online sales of weight-loss products although mostly from browsers identifying themselves as Internet Explorer, Netcraft confirms it!

    2. Re:premise to shutdown by Qzukk · · Score: 4, Funny

      This has greatly increased the online sales of weight-loss products although mostly from browsers identifying themselves as Internet Explorer

      Linux users were terminated by their modified kernel after it detected that they were exercising ;)

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    3. Re:premise to shutdown by Anonymous Coward · · Score: 0

      "What we've got here is failure to communicate."

    4. Re:premise to shutdown by Anonymous Coward · · Score: 0

      thats not excercise you insensitive clod!

    5. Re:premise to shutdown by sgt+scrub · · Score: 1

      In the news today

      Thousands of System Administrator machines abruptly stopped working when emails with girl's names in them went to women that did not charge by the hour.

      Film will be available when the System Administrator is able to access the streaming media server again.

      --
      Having to work for a living is the root of all evil.
    6. Re:premise to shutdown by ThatFunkyMunki · · Score: 1

      Have we been reduced to the level of mere animals?

      --
      If patriotism is racist, is racism patriotic?
  3. selinux by perlchild · · Score: 4, Interesting

    Great, sounds exactly like what people have been doing with selinux and capabilities. But selinux acknowledges we don't always do the same things with our computers as the next guy... Will this approach be as flexible?

    I don't want to boohoo his research, it's probably fine, but the article summary just gets my goat. Malware is a lot more complicated than most anti-malware software authors make them sound, and false positives are the biggest/most complicated problem they have to deal with, especially in automated systems that block like this...

    1. Re:selinux by icsx · · Score: 5, Interesting

      If you can detect and isolate a program that doesnt do what it is supposed to be doing and attracts attention with unusual behaviour, like scanning certain ports or trying to send packets etc, then it may be something that you dont have to have on your server. Most security programs today arent looking up what software does. They look what ports are used, what traffic is routed and so on.

      These malware programs today try to hide themselves into deep that you just couldnt find them if you dont know what you are looking for. This system here as i understand it tries to identify what are the normal parameters for a certain program to work. If the program doesnt do or behave like a normal software, then there must be something wrong with it and alarms go off, lights are blinking and all hell brokes lose.

      Oh crap, red lights and i hear noises. Oh it's only the cops.

    2. Re:selinux by Kjella · · Score: 5, Informative

      Well, from my basic reading of the paper it sounds like it won't have false positives but it also will miss many negatives. Essentially when you build it it'll make a map of what system calls can be made and in what sequence. If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it. If you manage to do your nasty business using the system calls it normally uses, it won't. Think of it as a auto-hardening system turning off any syscalls or combinations that the application doesn't use anyway. One of the downsides is that if you know this system is in place, you can probably add dummy syscall patterns to your exploit to match the application's behavior unless it's a syscall it never does. Still, there's little reason assuming an attacker is perfect and this is a worthwhile protection for the cases where it does work.

      --
      Live today, because you never know what tomorrow brings
    3. Re:selinux by Anonymous Coward · · Score: 0

      I came to post a witty remark about SELinux and how it's been doing this for years now, but you got ahead of me. Thanks for stealing my thunder.

      A correctly labeled filesystem and SELinux solves these woes. Do we need another one?

    4. Re:selinux by Anonymous Coward · · Score: 0

      So... how is this not SELinux?

    5. Re:selinux by Anonymous Coward · · Score: 1, Interesting

      Essentially when you build it it'll make a map of what system calls can be made and in what sequence. If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it.

      Or the application has been legitimately updated to do new things...

    6. Re:selinux by Plouf · · Score: 3, Insightful

      If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it.

      The problem is that, for any non-trivial program, it is impossible for a static analyser to decide whether the software will call or not and in what order a specific trap. For instance, that static analyser is not able to tell you in advance at what time the exit syscall will be called.

    7. Re:selinux by Anonymous Coward · · Score: 0

      This is an unwinnable war. It simply is not possible to obtain the required 100% accuracy by writing scanners to check hueristically for shady activity.

      selinux is a good approach in some areas because it constrains execution to only the resources each application is expected to need.

      Again manual work needed to define the execution parameters of each program.

      Our only hope moving forward is better software/trusted execution not these rediculous hueristic scanners that will not even function properly when computers are smarter than humans.

    8. Re:selinux by debatem1 · · Score: 4, Informative

      This is actually quite different from selinux, although they both hinge on controlling what syscalls a program can make. The major difference here is that this system automatically builds an equivalent to the selinux rules at compile time, and therefore avoids a lot of the problems caused by poorly written selinux rules. An associated advantage is the ability to track whether a chain of syscalls is legitimate. Such context analysis could be very powerful if used properly.

      However, you've probably already spotted the major flaws with this approach: the first is that it only works on compiled programs, which strikes me as a serious problem when you're talking about webservers. The second is that it doesn't work on certain classes of programs whose execution pattern is extremely difficult to predict: self-modifying code, highly dynamic code (longjmp is not allowed), etc. Another limitation is that it only works on statically linked libraries. Finally, it is totally dependent on GCC and friends, which could be a problem for it moving forward, and in groups where the intel compiler is preferred.

      As for false positives, the entire point of this is that inside of these admittedly limited confines, it has no possibility for false positives. This system is not statistical in nature. It depends entirely upon the program itself to determine correct syscall behavior.

      All in all, while it is a long way from a practical security model, it does offer the promise of powerful, accurate protection from certain classes of attacks. When combined with selinux and pcap on a system with a slim attack profile it could help to narrow the gap between being a zero-day compromise and having full protection.

    9. Re:selinux by Kjella · · Score: 3, Informative

      Or the application has been legitimately updated to do new things...

      Well that part is handled. The call map is made when the application is compiled, so new source equals new map. That's at least one advantage over SELinux, this is completely automatic and it's always correct in that sense. Though if you want to get this with precompiled binaries, you also have to get precompiled maps so the distros have to help you out - it's not something you can set up on existing binaries on your own.

      --
      Live today, because you never know what tomorrow brings
    10. Re:selinux by perlchild · · Score: 1

      On the other hand, it's strong where selinux is strong(the applcations etc.. are well known... and the context restricted. While I had hope for an approach that required a kernel mod to work, to actually be able to secure that open moat of computing ... the shared hosting server...

      Seems all the work is going in applications server, where the hardware is dedicated and the resources are already plenty... And almost no work is going into securing the already at risk segments... (Think the resold cpanel server market)

    11. Re:selinux by QuoteMstr · · Score: 2, Insightful

      It can't catch every case, but it can rule out a lot of system calls. If setuid never appears in a program or library's source, it can't be called. If a program calls a bunch of things in an initializer function and then enters a more restricted main loop, the static analyzer should be able to catch that too.

      I can't see how this approach could hurt, though of course it won't catch everything.

    12. Re:selinux by debatem1 · · Score: 2, Informative

      If you're looking into securing a shared hosting solution, you might look into libpcap. I mentioned it before, but it gets far less attention than it deserves, especially among admins. It has the capability to forbid forming new chroots, making modifications to your networking properties, the insertion of kernel modules, even escalations to root. Between libpcap, something like this, a well-constructed jail, a good vserver solution, and a very carefully secured network, you're going to be as secure as just about anything out there.

    13. Re:selinux by andreyvul · · Score: 1

      /And/ LFS users, however few.

      --
      proud caffeine whore
    14. Re:selinux by Anonymous Coward · · Score: 0

      So how does it handle plug-ins? It's not like your web browser knows what system calls the Flash plugin is going to make.

      dom

    15. Re:selinux by emj · · Score: 1

      you also have to get precompiled maps so the distros have to help you out

      This was in ggp post, of course you can get maps for every distribution if this takes off.

    16. Re:selinux by leuk_he · · Score: 1

      I can see the hurt. 20% of an application is used 80% of the time. There are some rare conditions in a program that are barely used ever, like adding a user or running the yearrun. These tasks may fail because they behave different.

      ??

    17. Re:selinux by An+ominous+Cow+art · · Score: 1

      I think you're talking about "libcap" (a capability library), not "libpcap" (a packet capture library).

    18. Re:selinux by debatem1 · · Score: 1

      Its funny you should mention that- I was.

    19. Re:selinux by debatem1 · · Score: 1

      Edit: spelling is my mortal adversary. The correct library is libcap.

    20. Re:selinux by debatem1 · · Score: 1

      Edit: I also screwed it up here. The correct library, as pointed out below, is not libpcap, but rather libcap. My bad.

    21. Re:selinux by Anonymous Coward · · Score: 0

      You don't build the packages, someone else does. They can do it when they build them, and simply include them in the package.

      Duh. Did you even try to think?

    22. Re:selinux by Anonymous Coward · · Score: 0

      Edit: spelling is my mortal adversary. The correct library is libcap.

      Cue the people who talk about how correcting anyone's spelling is needless and nitpicky. They're awfully quiet on this one, funny that. You see, whether proofreading will actually matter or not isn't always something you can determine in advance. The only remedy for that is to do it all the time so you're covered (or at least made an effort) for the cases where it matters.

  4. Heuristic scanning v2.0? by mlts · · Score: 1

    I could be wrong but this sounds like the heuristic scanning features that has been in Norton Antivirus and other A/V utilities for almost a decade now, where it searches for out of the norm items and reports or blocks them, such as a program deciding to write to the MBR, or a program using raw disk I/O to write to the hard disk.

    1. Re:Heuristic scanning v2.0? by ThinkingInBinary · · Score: 5, Interesting

      this sounds like the heuristic scanning features that has been in Norton Antivirus and other A/V utilities for almost a decade now, where it searches for out of the norm items and reports or blocks them, such as a program deciding to write to the MBR, or a program using raw disk I/O to write to the hard disk.

      Wow, those "heuristics" sound like a simple blacklist of "virus-like" activities.

      No, what this does is cleverer. It creates (at compile time) an automaton representing the system call activity of the program, and if the program tries to make a syscall that does not have a matching edge in the automaton, it kills it. Basically, if there is not a code path that should lead to execution of a certain syscall, the program gets killed.

    2. Re:Heuristic scanning v2.0? by Anonymous Coward · · Score: 0

      Considering this is a University level research paper,... I dont think their techniques are limited to watching for raw disk I/O and MBR modification. I would assume its more somewhere along the lines of a program that profiles applications for all their IO (Disk read, Disk write, Net ports standby, Net ports sending) as well as their resource requirements, mix in a little mathematics and you get a probabilistic approximation of a program's "spywareness" according to what it's probably trying to do.

    3. Re:Heuristic scanning v2.0? by larry+bagina · · Score: 1

      That sounds cute, but I don't see how it helps all that much. If you download and run a trojan/malware that deletes all your files, it's doing what it's supposed to be doing, so it's not malware. If (for example) apache has a buffer overflow/stack smashing problem that lets mr hacker run arbitrary code, that code can still make the same syscalls apache makes.

      --
      Do you even lift?

      These aren't the 'roids you're looking for.

    4. Re:Heuristic scanning v2.0? by QuoteMstr · · Score: 1

      It's more clever than that. Imagine a program always called select(), read(), and write() in that order. Through static analysis at compile time, you guarantee that's all the program should be doing. If you observe the program run select(), setfsid(), write(), it can't be running the code it was compiled with, and so it should be killed.

    5. Re:Heuristic scanning v2.0? by liquiddark · · Score: 2, Funny

      So basically it shuts down malware and buggy software. Holy fuck, somebody kill this thing - we're all out of a job if this catches on.

    6. Re:Heuristic scanning v2.0? by V!NCENT · · Score: 1

      It shuts down that which is unexpected. A clever mind could easily copy behavior of heavy, common root pogram and *BOOM!*... hello private files...

      --
      Here be signatures
    7. Re:Heuristic scanning v2.0? by azgard · · Score: 1

      What about threads? They will show different signature each time.

      You have two threads; one of them dies.

    8. Re:Heuristic scanning v2.0? by hksdot · · Score: 0

      This kind of modeling has been around for years in various forms. Unfortunately, despite the article (which, since this is slashdot, is vapid, naturally) plugging the technology, the approach is pretty narrow. Techniques such as non-executable data (e.g. in hardware the NX bit) and randomization (e.g. ASLR in use in Linux and Vista) provide more broad defense and better performance than this technique.

      In summary: this is old hat, and it certainly will not revolutionize malware detection or replace current anti-virus products.

  5. Oh great. by bigtallmofo · · Score: 5, Funny

    They recently unveiled a unique new program called the "Korset" to stop malware on Linux...and once it reaches its full potential it could put anti-virus software companies out of business.

    Doesn't our economy have enough problems? Do we really need to put Linux anti-virus vendors out of business? Next we'll probably drive the ice vendors in Alaska to bankruptcy!

    --
    I'm a big tall mofo.
    1. Re:Oh great. by fuzzyfuzzyfungus · · Score: 5, Funny

      Oh, don't worry. Things are just warming up for the ice vendors...

    2. Re:Oh great. by Eighty7 · · Score: 1

      I hope they enjoy their moment in the sun, because they'll soon be in over their heads.

    3. Re:Oh great. by morcego · · Score: 1

      Joking aside, there are plenty of anti-virus companies with Linux products. AVG and F-Prot are 2 I use regularly (on servers, to protect the Windows machines connected to them).

      In a particular client of mine, about 40% of the yearly anti-virus license payments are related to Linux server licenses (the other 60% is, of course, related to the workstations/desktops).

      So yeah, while the home market for Linux anti-virus software might be close to nill, on the corporate segment it is fairly significant.

      And yes, I know you can't extrapolate a market figured based on the example of a single company (the client of mine I mentioned), since on many companies they will have Windows servers with anti-virus software. My guesswork for this would be that maybe 3% of the corporate market for anti-virus is related to Linux (or other Unices flavors). Even if not huge, it is far from insignificant. The biggest proof is the number of av companies with Linux products is increasing everyday.

      --
      morcego
    4. Re:Oh great. by kimvette · · Score: 1

      Question: why don't you go the F/OSS route and use ClamAV?

      --
      The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
    5. Re:Oh great. by morcego · · Score: 1

      Because ClamAV is SLOW.

      I have tested Samba servers running both Clamav and F-Prot. The access times on files, when running f-prot.so, was pretty much the same. However, when using clamav.so, it became so slow (relatively) that some programs started having problems.

      I still use clamav on non speed critical environments (like e-mail servers). But for file servers, it is simply not an option.

      --
      morcego
    6. Re:Oh great. by gad_zuki! · · Score: 1

      >Next we'll probably drive the ice vendors in Alaska to bankruptcy!

      Naww, there's always a demand for governors lying in their tanning beds sipping iced tea while keeping an eye on those pesky russians.

    7. Re:Oh great. by An+ominous+Cow+art · · Score: 1

      It's Ok, the government will bail them out before they drown.

  6. How it works by Animats · · Score: 3, Interesting

    From the papter: "The resulting model is an automaton that represents the legitimate order of system calls that an application may issue. This automaton is then enforced by Korset's monitoring agent, which is built into the Linux kernel, by simulating every emitted system call."

    This is not likely to work for scriptable applications (Apache, Java-based servers, etc.) The order of calls is determined by the script, not the underlying executable.

    1. Re:How it works by UnderCoverPenguin · · Score: 1

      From the paper: "The resulting model is an automaton that represents the legitimate order of system calls that an application may issue. This automaton is then enforced by Korset's monitoring agent, which is built into the Linux kernel, by simulating every emitted system call."

      Why couldn't malware makers then just insure their programs emulate this profile?

      --
      Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
    2. Re:How it works by Anonymous Coward · · Score: 0

      Why couldn't malware makers then just insure their programs emulate this profile?

      Ensure. The word is ensure, unless you are expecting them to take out a policy that will pay them in the event of the loss or destruction of said programs.

      You're welcome.

    3. Re:How it works by QuoteMstr · · Score: 1

      Why couldn't malware makers then just insure their programs emulate this profile?

      No, because the whole point of malware is getting a program to do something other than what it's supposed to do, and the profile describes, well, what the program's supposed to do.

    4. Re:How it works by RiotingPacifist · · Score: 1

      I see now is not a good time use the word insure around Americans!

      On topic,

      Why couldn't malware makers then just insure their programs emulate this profile?

      They could but this
      1) makes it a trickier to write the malware
      2) limits the scope of damage the malware can do to what the program is doing (much like selinux)

      --
      IranAir Flight 655 never forget!
    5. Re:How it works by nog_lorp · · Score: 1

      It will work to a degree: the scripts can be perverted at the script level - in theory java could be caused to run arbitrary java. But this would still protect against lower level exploitation via scripting languages. Arbitrary script but no arbitrary code (unless it can be achieved through legal script).

      Also, it would bock in response to anything scripting language that would allow constructing lower level calls.

    6. Re:How it works by SmackedFly · · Score: 1

      Not true. The script runs certain functions in the executable, but it still stays within the call boundaries allowed by the executable that runs the script. Unless the executable have a function for each system function, you cannot simply choose which system functions to call, you will still be limited to what the scripting environment allows.

  7. This could be a serious problem! by cavehobbit · · Score: 1

    If I stop surfing pr0n will it detect that anomaly and halt my browser?

    Will that crash my gnome desktop too?

    Oh NO!

    1. Re:This could be a serious problem! by Anonymous Coward · · Score: 1, Funny

      If I stop surfing pr0n ...

      Why deal with hypotheticals that we know will never occur in real life?

  8. Ummmm..... by Hasai · · Score: 2, Informative

    ....I thought that was the philosophy behind AppArmor (http://en.opensuse.org/Apparmor).

    It's been deployed in SuSE products for years.

    --

    Regards;

    Hasai

    1. Re:Ummmm..... by Lennie · · Score: 1

      Also the BSD's have something similair I've heared (and forgot the same)

      --
      New things are always on the horizon
    2. Re:Ummmm..... by causality · · Score: 3, Informative

      ....I thought that was the philosophy behind AppArmor (http://en.opensuse.org/Apparmor).

      It's been deployed in SuSE products for years.

      Apparmor seems to be a relatively sophisticated least-privilege system, i.e. the idea that if a BIND DNS server should never need to (for example) modify the routing table, then it also should not be able to modify the routing table. That way, if an attacker compromises said DNS server, he won't be able to do very much with it that isn't directly related to serving DNS requests (this is why I would personally refer to such a system as damage control, useful for containing/limiting an attacker who has already compromised something). The system discussed in the article is different in that it seems to be less concerned with what specific tasks a program should or should not be doing and more concerned with whether the code that is executed and the way that it is executed is what you would expect from the program's source. That way, if someone exploits i.e. a buffer overflow and inserts their own shellcode, it would deviate from the pattern that you would have expected from the exploited program and this deviation would be detected.

      Both can be compared to systems like PaX (kernel) and SSP (userspace) which are intended to make sure that an attacker will fail to exploit an existing vulnerability, such as an unpatched buffer overflow, in the first place.

      --
      It is a miracle that curiosity survives formal education. - Einstein
  9. I'm definitely not an expert... by fuzzyfuzzyfungus · · Score: 4, Interesting

    But this looks a lot like SElinux or AppArmor, except that the application profiles are constructed by static analysis of program code, rather than by hand, or by observing the app during a "training" period. The linked paper indicates that it is still in a rather rough state; but it looks quite promising.

  10. Linux?? by fxkr · · Score: 2, Informative

    I really don't think Linux has problems with malware. I think there is an other operating system having more trouble.

    As far as I know virus scanners are used on servers mostly to check data that goes through it (example: email server); this data will however not be executed on the server.

    1. Re:Linux?? by Alain+Williams · · Score: 1

      I really don't think Linux has problems with malware. I think there is an other operating system having more trouble.

      Maybe, but we still need to work hard to ensure that that is the case; why do you think that SELinux and stack randomisation have been developed ? Remember: pride becomes before a fall!

    2. Re:Linux?? by jimicus · · Score: 1

      I really don't think Linux has problems with malware.

      Yet.

      Not a lot of /. readers seem to know this but (whispers) most modern Windows malware doesn't depend on the user having administrative privileges.

      IOW, a program which, when executes, deletes all your documents then emails itself to all your friends can exist just as easily on Linux as it can on Windows. About the only thing preventing that right now is that nobody's got around to it and it would still require some effort on the users part because AFAIK no Linux mail client will perform file(1) on attachments and chmod u+x them where appropriate by default.

    3. Re:Linux?? by fxkr · · Score: 1

      Correct, but from the article (emph mine):

      "Prof. Wool and Ben-Cohen have built an open-source software solution for servers that run on Linux."

      Would you run anything anyone sent you on your mail server? Probably not.

      In a desktop environment, their software might be more useful.

    4. Re:Linux?? by RiotingPacifist · · Score: 1

      Nothing can stop the dancing bunnies, NOTHING.

      --
      IranAir Flight 655 never forget!
  11. I Remember This... by Anonymous Coward · · Score: 0

    It's called TRON. It's a security program itself, actually... It monitors all connections between our system and other systems. If it sees anything going on that's not scheduled, it shuts it down.

  12. SELinux on steroids by PingXao · · Score: 0

    SELinux controls what resources are used and where. This sounds like it monitors HOW processes behave. SELinux is over hyped. This sounds like a nightmare to configure and control the heuristics. You tweak it and tweak it to avoid false positives and then, inexplicably, it fails to stop something, and what good was it?

  13. So what? by Plouf · · Score: 1

    So they are comparing the program behavior and match it with a stripped version of the source code or the object file. Great! But what are they protecting themselve against exactly? If some virus tampered with the content of a binary or a shared object, whouldn't be more effective to implement a (trivial) checksum-based integrity mechanism? And if a black hat managed to feed a shell code through a buffer overflow, how will this tool distinguish between a legitimate fwrite in the software logfile against an fwrite to some other part of the disk?

    Also, their fwrite example already yields a highly complex graph. I would like to see what snprintf gives, not to speak about any real-life software (say, a Java Application Server). You can't automatically predict what path a program will follow by just looking at the code (otherwise you would solve the halting problem), so I guess a non-trival program would give something like "any system call will occur anytime".

    1. Re:So what? by Lennie · · Score: 1

      I think they want to prevent running programs that have had a some kind of overflow and there 'code rewritten' to be able to do things they were never intended to do. And by using source-code analysis this might be an easier way to construct a lot of a program is allowed to do.

      --
      New things are always on the horizon
    2. Re:So what? by Anonymous Coward · · Score: 0

      I don't think the halting problem applies here. It is true that it would be the halting problem if you ask: Will the program execute x after y?

      But it suffices to answer the question: Is the program in a valid state? Using static code analysis you can create a map of all relevant calls with arrows indicating which call can be executed next. With the graph you can build a finite state machine.

  14. Not a good article, but an interesting paper. by argent · · Score: 4, Insightful

    OK, what this is doing is watching for code injection attacks (buffer overflows, stack smashing, etcetera) by building a model of how each specific application is going to operate, and blocking system calls that the model of the application would never make. It seems like an interesting approach, though it may not be as useful on Windows where there's not such a formal distinction between system calls and other kinds of calls.

    It won't do anything about interpreter code injection (eg, SQL injection or shell code injection) or script privilege escalation attacks (eg, ActiveX and other "cross zone" attacks in Internet Explorer), or attacks that involve complete executable code drops.

    Still, this is useful and not nearly as dodgy as the article made it sound.

    1. Re:Not a good article, but an interesting paper. by AnEducatedNegro · · Score: 1
      i don't think you fully understand the process they are describing.

      It seems like an interesting approach, though it may not be as useful on Windows where there's not such a formal distinction between system calls and other kinds of calls.

      can i have some of what you're smoking? if my exchange server is compromised and starts to serve webpages by binding to a port other than port 25, this method would catch it and kill the process in its tracks. this is an os-agnostic approach to stopping malware, they just used the linux kernel because its free.. don't be surprised if you see these kind of features appearing in every major compiler/os over the next few years.

      It won't do anything about interpreter code injection (eg, SQL injection or shell code injection)

      You application, which normally never spawns a procses while in a certain function, will be killed as soon as it attempts to execute because it violates the model that was created at compile time.

      or script privilege escalation attacks (eg, ActiveX and other "cross zone" attacks in Internet Explorer), or attacks that involve complete executable code drops.

      it is designed to stop "cross zone" attacks, but it depends on the application developer's approach. i.e. ie7 would not benefit from this trick, but ie8 would (each zone is spawned in a new thread)

      Still, this is useful and not nearly as dodgy as the article made it sound.

      this should help curb the outrageous memory and cpu usage of the typical blacklist virus scanners of the present.

    2. Re:Not a good article, but an interesting paper. by supernova_hq · · Score: 0, Flamebait

      this is an os-agnostic approach to stopping malware, they just used the linux kernel because its free.. don't be surprised if you see these kind of features appearing in every major compiler/os over the next few years.

      The day Microsoft does anything truly smart to prevent malware is the day they switch to a linux kernel!

    3. Re:Not a good article, but an interesting paper. by argent · · Score: 2, Informative

      if my exchange server is compromised and starts to serve webpages by binding to a port other than port 25, this method would catch it and kill the process in its tracks.

      On the other hand, if your exchange server is compromised and starts shipping spam it won't do a damn thing to stop it. And if your exchange server is compromised and loads a DLL using its normal API for loading modules, then it can do anything that module will attack.

      You application, which normally never spawns a procses while in a certain function, will be killed as soon as it attempts to execute because it violates the model that was created at compile time.

      It only tracks system calls, not functions (that would have insane levels of overhead), and it cant even see what the interpreter thinks of as functions. Any time an interpreter is involved, the call graph will be "bushy" because all possible operations that the interpreter supports will be legal as the "next step" from each step in the interpreter loop.

      it is designed to stop "cross zone" attacks, but it depends on the application developer's approach. i.e. ie7 would not benefit from this trick, but ie8 would (each zone is spawned in a new thread)

      I think you're confusing cross zone attacks (attacks on the security zone model in Windows) with cross-site attacks.

      this is an os-agnostic approach to stopping malware, they just used the linux kernel because its free.

      Also, Linux has a formal "system call" interface, so they have a single point of entry with well behaved semantics and known overhead, so they can control the impact of their technique very closely. They can't put this in all Windows call gates, they'll have to pick particular DLLs that they track, and maybe even limit the calls they track (you don't want anything that's doing frequent callbacks to be tracked, for example).

    4. Re:Not a good article, but an interesting paper. by Alpha830RulZ · · Score: 1

      The day Microsoft does anything truly smart to prevent malware is the day they switch to a linux kernel!

      You say this like you think it's something that will never happen. Google David Cutler, VMS, and NT. Microsoft has learned/copied from other solid OS's before, and I think it's a safe conclusion that they probably will again. Linux's success is not lost on the boys from Redmond.

      It bears repeating, MSFT's primary problem with malware is simply that they are the biggest target.

      --
      I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
    5. Re:Not a good article, but an interesting paper. by marcosdumay · · Score: 1

      "And if your exchange server is compromised and loads a DLL using its normal API for loading modules, then it can do anything that module will attack."

      That's true, but as far as I can see, there is no reason that the same concept couldn't be applied to dynamic linking for most programs. The exception being the programs that construct library names at run-time, what should amount to 1 or 2 executables at an entire system.

    6. Re:Not a good article, but an interesting paper. by argent · · Score: 1

      That's true, but as far as I can see, there is no reason that the same concept couldn't be applied to dynamic linking for most programs. The exception being the programs that construct library names at run-time, what should amount to 1 or 2 executables at an entire system.

      That exception includes every program that uses or provides a plugin architecture. On Windows, that includes Exchange, IIS, and every program that uses COM and ActiveX, like Microsoft Office and Internet Explorer.

    7. Re:Not a good article, but an interesting paper. by marcosdumay · · Score: 1

      Yep. You are right. That also includes Apache, LightHttpd, PostgreSQL, Exim and others.

    8. Re:Not a good article, but an interesting paper. by argent · · Score: 1

      Oh yes, it's definitely limited to a subset of applications on any platform. Windows is just particularly hard because things like COM are so pervasive.

      Again, that doesn't mean it's useless. It does seem to nail executable code injection attacks pretty effectively.

  15. LINUX has viruses, not as many, like usercounts! by Anonymous Coward · · Score: 0

    Not meaning to be 'dork' about this, per my subject line, but... pointing out some facts:

    New MacOS and Linux virus found in the wild:

    Per my subject-line? Linux does INDEED, have viruses (no immunity, sorry to blow your 'illusion'):

    http://it.toolbox.com/blogs/locutus/new-macos-and-linux-virus-found-in-the-wild-15440

    From 2007... but, point IS there (for both Linux AND the MacOS X too)

    APK

    P.S. => Also, from the "POV" of say, a botmaster or otherwise misguided person - THINK about this, for a second:

    Say, YOU were out to 'make monies' suckering others via botnets etc. OR, just out to "blow their machines" & do other mischief... wouldn't YOU attack the largest block of users out there, & those possibly/potentially less "technical" than a std. *NIX head might be??

    (After all, isn't *NIX & its variants GENERALLY the province of more "geeky types" (excepting MacOS X that is, it's built to be "useable by gramma" etc. et al), that most likely could not ONLY shut the damn thing down & spread it to others quickly in the *NIX community how to do so, but also, attack back...? You'd most likely avoid them...

    Thus, Windows IS going to have more of this happening, because it's more used. Plus, javascript + iframes (biggest attack vectors there is via webbrowsers &/or email programs no less the past 3-5 yrs. now)... do they run on LINUX &/or *NIX in general? Yes, they do. You're, in theory, JUST as vulnerable... just not as oft targetted... apk

  16. I've heard this idea before from an IBM researcher by PolygamousRanchKid+ · · Score: 1

    This was about 10+ years ago.

    The guy was from the IBM Zurich Lab, and was pushing to get it implemented in the AIX kernel.

    It's probably patented, but IBM does allow a bunch of patents to be used for Linux. Or maybe he lost his funding and his project died.

    If I'm bored tonight, I'll try to google it out.

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
  17. What about BIOS? by Anonymous Coward · · Score: 0

    I've suffered through at least one motherboard whose BIOS attempted to detect and stop viruses. What a phenomenal pita that was. I can't see kernel based virus prevention being a lot better.

  18. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    The link you sent us to is just double speak and presents no evidence of any virus found in the wild, except for one persons wild claim and even more bizarre explanation of how this "virus" is supposed to work. Sadly he is describing the action of a worm, not a virus, so even that is wrong.

  19. Completely incorrect basic assumptions by non-e-moose · · Score: 1

    This is drivel - it assumes that a static binary analysis can be used to predict the dynamic behavior of a non-trivial application, with zero false positives. Unless of course, "benign intent" equates to "trivial". As a concrete counter-example, witness the (rather old) Solaris telnet bug wherein a specific input string coupled with a particular environment variable could result in the skipping of requiring a password. A simple model based upon the CFG would indicate that this is a legitimate possibility. My qualifications in this area: multiple product-grade binary translators and binary optimizers; former developer (Okena/Cisco) of a HIPS (Host Intrusion Prevention) system where we actually had to worry about this kind of problem.

    1. Re:Completely incorrect basic assumptions by russotto · · Score: 1, Insightful

      This is drivel - it assumes that a static binary analysis can be used to predict the dynamic behavior of a non-trivial application, with zero false positives.

      Which is why I tagged this with "haltingproblem". If it's impossible to write a terminating program which simply determines whether or not another program terminates, just how likely is it that a program can correctly predict far more complex behavior of another program? Since the halting problem is noncomputabe, we know it can't do it with 100% reliability, the question is: "how error prone is it?"

    2. Re:Completely incorrect basic assumptions by QuoteMstr · · Score: 4, Interesting

      You're right. You can't exactly predict the behavior of a program without running it.

      But that's not what this package is trying to do. Instead, it's trying to rule out large swaths of the behavior space of a program based on static analysis. Of course there will be false negatives -- i.e., malicious actions that remain undetected. But I don't really see how false positives would be a danger, modulo bugs in the static analyzer.

      I imagine this package would be nearly useless for something like firefox, which does many varied tasks. But for programs like exim, or bind, or vsftp -- which do one task over and over again -- the degree of protection should be pretty good because there's a lot these programs don't do.

    3. Re:Completely incorrect basic assumptions by Anonymous Coward · · Score: 2, Informative

      The halting problem is a nice thing, but don't throw it at everything that looks like static analysis.

      You can take any program and build a directed graph. The nodes are instructions. You add an arrow a=(x,y) to it, if after executing x the instruction pointer can be at y. No halting problem here. To be more precise the graph is build in O(n) with n being the number of instructions in the program.

      Now imagine you leave out most instructions, and consider system calls only. Still no halting problem.

      Now if you are given a list of system calls you can use the graph to decide if it is possible for the program to execute in that order. You get zero false positives.

    4. Re:Completely incorrect basic assumptions by Anonymous Coward · · Score: 0

      I imagine this package would be nearly useless for something like firefox, which does many varied tasks.

      Firefox doesn't need to call setuid(). Firefox doesn't need to open block devices. Firefox doesn't need to chroot() - although it ought to be inside one in the first place, and if it is, calling chroot() again may be an attempt to break out.

    5. Re:Completely incorrect basic assumptions by QuoteMstr · · Score: 1

      Firefox might open /dev/{sounddevice}. And Firefox can't call chroot anyway: it's not running as root.

      Your comment illustrates perfectly why application profiles should be created by static analysis and not humans.

    6. Re:Completely incorrect basic assumptions by silent_artichoke · · Score: 1

      My qualifications in this area: multiple product-grade binary translators and binary optimizers; former developer (Okena/Cisco) of a HIPS (Host Intrusion Prevention) system where we actually had to worry about this kind of problem.

      Yes, but do you speak Bocce?

    7. Re:Completely incorrect basic assumptions by Anonymous Coward · · Score: 0

      Read the paper. "We show that the derived model can prevent future or unknown code injection attacks (such as buffer overflows) with guaranteed zero false alarms."

      It also incorrectly assumes that 100% coverage can be arrived at via training.

    8. Re:Completely incorrect basic assumptions by petermgreen · · Score: 1

      You can take any program and build a directed graph. The nodes are instructions. You add an arrow a=(x,y) to it, if after executing x the instruction pointer can be at y. No halting problem here. To be more precise the graph is build in O(n) with n being the number of instructions in the program.
      Nice idea but there are some things that can throw a spanner in the works. Function pointers are one, inheritance with dynamically loadable classes is another.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  20. Just trying to understand by pjt33 · · Score: 1

    It creates (at compile time) an automaton representing the system call activity of the program

    At compile time of the program? So in addition to a modified kernel you need a modified gcc and to compile everything from source or have a specialised distro? It doesn't surprise me that the summary should be lacking such details, but it would be nice if for once it gave a decent overview.

    1. Re:Just trying to understand by causality · · Score: 4, Informative

      It creates (at compile time) an automaton representing the system call activity of the program

      At compile time of the program? So in addition to a modified kernel you need a modified gcc and to compile everything from source or have a specialised distro? It doesn't surprise me that the summary should be lacking such details, but it would be nice if for once it gave a decent overview.

      I agree that this was a poor summary but instead of complaining about the summary you could always do something crazy like read the article.

      --
      It is a miracle that curiosity survives formal education. - Einstein
    2. Re:Just trying to understand by Rich0 · · Score: 1

      Well, if something like this took off programs could come with execution fingerprint files or whatever containing this information. However, that just means that instead of downloading a virus-infected executable you'll just end up downloading the virus-infected executable and its infected fingerprint.

      The issue with any scanner like this is that you need to start from a known-good state. If you take all the time to maintain it a system like tripwire is virtually impenetrable - even if there is a break-in it is a trival matter to identy any compromised files.

      You could also just have a CD-ROM full of MD5 sums mounted and have the kernel checksum any file before executing it. I can't see how that would be any less secure - or inconvenient.

      Where I see this being useful is in an enviornment like a server with infrequent updates (running debian stable or the like). That's the same enviornment where tripwire (or an in-kernel equivalent) is useful.

    3. Re:Just trying to understand by pjt33 · · Score: 1

      Well, if something like this took off programs could come with execution fingerprint files or whatever containing this information.

      That's what I meant by a specialised distro - unless by "take off" you mean that Linus copies it to trunk.

      The issue with any scanner like this is that you need to start from a known-good state.

      I could be wrong - I haven't RTFA, just some of the comments on this thread - but my understanding is that it's not anti-virus but anti-buffer-overflow. In other words, the instructions which it's stopping aren't in the executable at all. I'm not sure* why this can't be fixed more easily by making the kernel memory management allocate non-adjacent sections for code and data such that a buffer overflow is either into more data or raises a segfault, but maybe that's why I'm not a kernel programmer.

      * I realise that there are a small number of applications which absolutely need to convert data into code - e.g. JIT compilers. I can see ways to fix that, but they would probably break existing libraries.

    4. Re:Just trying to understand by Anonymous Coward · · Score: 0

      Well ID indicates you're not that new around here.... you just must not come by that often....

    5. Re:Just trying to understand by Rich0 · · Score: 3, Informative

      I wonder if a fix for the buffer overflow (besides languages that make it harder) would be to separate the stacks used for local variables and return addresses.

      The problem is that when a call is made to a function the compiler pushes the return address onto the stack. Then the function allocates space for its own variables on top of the same stack. If one of those variables overflows it can hit the return address. That essentially is a mixing of code and data. If you had two stacks then the processor could trigger an exception if anything writes to one of them except via a call or return. You could probably accomplish this via changes to the compiler without a processor change - the processor will always use the regular stack but a compiler could be designed to maintain a separate stack for local variables. You wouldn't have that read-only protection on the regular stack, but the two would be in different segments making an overflow impossible.

      Other tricks that are used are things like canarys - values written onto the stack and then checked before a return - if there was an overflow the canary would not be intact. GCC has an option to do this which works most of the time.

  21. CylantSecure, it's been done before... by Anonymous Coward · · Score: 0

    CylantSecure has been doing this for about 8 years. They put hooks in the kernel and run a model to detect deviance in the kernel processes from the model. The model can be generated from usage and modified to fit changes in usage. So, is this new korset open source? If it's not It' not news.

    1. Re:CylantSecure, it's been done before... by QuoteMstr · · Score: 1

      I think the difference is that CyberSecure's model is generated from usage, while this package's model is generated with static analysis.

      I'm leery about usage-based profiling. What if there's a perfectly legitimate code path that the program just doesn't take while you're generating the profile? The program could be killed for something innocuous. I don't want that danger.

      The nice thing about static analysis is that it's always correct!

  22. Oh Great.... by Anonymous Coward · · Score: 0

    So that means Office 2003/7 running on wine will be seen as malware. Well, I guess that isn't such a bad thing.

    Cheers.

  23. how is this better than grsec or selinux? by NynexNinja · · Score: 1

    Not sure how this is better than what grsec and selinux does... They might be better suited to writing selinux modules than trying to reinvent the wheel here with what basically sounds like role based access control (RBAC) found in selinux

  24. Wait a minute... by Fri13 · · Score: 0

    "We modified the kernel in the systemâ(TM)s operating system so that it monitors and tracks the behavior of the programs installed on it"

    If they modified Linux kernel, they modified then the Linux operating system and not just kernel, because Linux is monolith kernel and not microkernel...

    1. Re:Wait a minute... by martinw89 · · Score: 1

      Uhhh... no. A monolithic kernel still uses a user space/kernel space separation. They're monitoring stuff that's happening in the user space by what system calls those userland applications make (to the kernel).

      If you considered a Linux kernel to be an entire operating system, you wouldn't be able to get a whole lot done on your computer. Think system libraries etc.

    2. Re:Wait a minute... by fxkr · · Score: 1

      If they modified Linux kernel, they modified then the Linux operating system and not just kernel, because Linux is monolith kernel and not microkernel...

      So is it still Linux?

    3. Re:Wait a minute... by Fri13 · · Score: 1

      Hmm... you call me as idiot because I did not mention that I know the monolith kernel has the kernel space and user space (kernel mode, userland) separation.

      But at least these speaks against your own comment.

        http://tinyurl.com/532kb8
        http://tinyurl.com/mum9x
        http://tinyurl.com/qhuhg
        http://tinyurl.com/3uaq48

      I am not sure but if few computer science professors speaks about against your "OS = kernel + userland, with no distinction between a microkernel and a monolithic kernel" I say SOMEONE is wrong. And I would bet my money for professors and not for you.

    4. Re:Wait a minute... by Fri13 · · Score: 1

      Operating System is not there to do lots of things for you. It is there to allow you to run all other applications and libraries etc in your computer hardware. And if you even try to mention that there is no difference about monolith kernel and microkernel structure, I say you should first say what is wrong with all these links.

      "This is a crucial, but subtle, point. The operating system is that portion of the software that runs in kernel mode or supervisor mode. It is protected from user tampering by the hardware (ignoring for the moment some of the older microprocessors that do not have hardware protections at all). Compilers and editors run in user mode."

      (first link, others follows even this same)

        http://tinyurl.com/532kb8
        http://tinyurl.com/mum9x
        http://tinyurl.com/qhuhg
        http://tinyurl.com/3uaq48

      After you have readed all those, tell me what is wrong on them with reasons and correct me! Because I want to know what is wrong on those if so!

    5. Re:Wait a minute... by QuoteMstr · · Score: 1

      I was wrong. Your original comment marked you as being ignorant.

      It's your reply that reveals your abject stupidity. Even if your links supported your ridiculous assertion, you'd be arguing by appeals to authority. Since they don't, you're arguing by appeals to a lack of reading comprehension.

    6. Re:Wait a minute... by Fri13 · · Score: 1

      Thanks for your comment. :-)

  25. Will fork bomb do work still? by DpakoH · · Score: 2, Interesting

    I'll try to run famous :(){ :|:& };: shell example

    1. Re:Will fork bomb do work still? by ZachPruckowski · · Score: 1

      Yes, it would still work. The method discussed here only checks whether a program is doing what it should, not whether what the program is doing is dangerous. If you compiled an application whose purpose was malicious, this wouldn't stop it (so you still need to download from known-good repositories and check MD5 hashes). It just stops code modification and code-injection attacks in compiled software.

      It's actually completely useless against a shell script, because if you're running a valid shell script on an unmodified shell, then it's perfectly within the program's capabilities (since by definition, a shell can do just about anything) and thus allowed.

  26. I might give it a spin by FudRucker · · Score: 2, Interesting

    When & if Linus Torvalds (or whoever the benevolent dictator of the kernel is nowadays) includes it in to the main kernel source tree...

    Sounds like a good idea to me, I just want to see what the Linux kernel pros think of it...

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:I might give it a spin by ZachPruckowski · · Score: 2, Interesting

      It seems too specialized to go in the main kernel tree. Additionally, I can only imagine that it hurts performance more than some users would like. Additionally, it requires a fundamental change to the system of distributing linux apps. Maybe a distro will include it in their kernel and modify their repository to include pre-built maps, but I can't see it becoming fully mainstream.

    2. Re:I might give it a spin by Anonymous Coward · · Score: 0

      This is not that big of a deal. As it's task_struct resident, it can be flipped on and off on a per-task basis. This can be handy if you trust your local services that are not exposed to the outside world, but don't trust your daemons and so on. In fact, we already have something like this in the kernel today -- seccomp. This moves a process in to a secure mode where it's only allowed to read/write/exec and to its existing fd table. Any attempt to invoke other syscalls or bind new fds results in the process being terminated. It's not hard to consider the approach in this paper being supported in a similar form.

    3. Re:I might give it a spin by marcosdumay · · Score: 1

      Not too specialized, since running servers is a very common use of Linux. Also, all the overhead goes away if it is activated by a flag at compile time, like lots of other Linux functionalities.

      Its biggest roadblocks seem to be the usual ones: very recent code that may have bugs, no maintence history (the Linux developers may want to wait a bit more to see if they won't get a bomb), politics...

  27. It's kind of like Vista by TheRealSlimShady · · Score: 3, Interesting

    Sounds from the summary at least (hey, it's slashdot, I haven't read the article) that it's similar in some ways to the service profiling in Vista. The service profiling means that the dev looked at what the service needed to do to be able to run and gave it only those permissions, restricting the damage it could do if it were compromised. This seems to extend that to give the kernel the intelligence to baseline the services itself, and then restrict activity when the baseline activity changes.

    1. Re:It's kind of like Vista by Delkster · · Score: 2, Interesting

      These guys make a point of avoiding the labour involved in manually building the profile. (FWIW, I don't know about anything service profiling in Vista -- in fact, I had never heard about it -- but your description also sounds somewhat reminiscent of AppArmor.)

  28. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    Check the date of the entry.

  29. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    Untrue, see here:

    http://www.securityfocus.com/columnists/188

    SALIENT QUOTE:

    "There are about 60,000 viruses known for Windows, 40 or so for the Macintosh, about 5 for commercial Unix versions, and perhaps 40 for Linux"

    There you go, & so much for your "refutation"...

    APK

  30. Looks like something AV has done for a while by Anonymous Coward · · Score: 0

    Hmm, am I missing something here.

    What he is describing is something that best AV packages have done on Windows for past couple years.

    1. Re:Looks like something AV has done for a while by Delkster · · Score: 2, Informative

      Their method is to automagically profile the software when it's compiled. That's obviously something antivirus software doesn't do.

      Antivirus software generally doesn't know how a particular piece of legitimate software is supposed to behave. The idea here is that the approach these guys are taking is exactly to try to build a profile for the normal behaviour of the application (or some parts of it, namely the pattern of syscalls). The analysis would be done at compile time, and when the application is being run its pattern of making syscalls would be matched against the known profile. That way the system could supposedly notice a compromised application or service because its pattern would be different than expected.

      Also, the method would be powerless against trojans, for example, because they don't work by exploiting vulnerabilities in legitimate software and changing the way it's executed. To me the suggested system seems more like just a potentially boosted intrusion detection system, not general malware-pattern detection, which is what antivirus software does.

      How well their profiling would actually work, that I don't know. Theoretically you can't make a complete analysis of all paths the execution of a program could possibly take (for an arbitrary program anyway). Multithreading and inter-process communication might make that even more difficult. But then, maybe it would be just possible to do it for some cases that practically occur with some decent probability.

    2. Re:Looks like something AV has done for a while by Anonymous Coward · · Score: 0

      Theoretically you can't make a complete analysis of all paths the execution of a program could possibly take (for an arbitrary program anyway).

      Yes you can (sort of), as long as the program is not self-modifying and you allow the inclusion of some impossible paths as well (i.e. you always get a maps of all the possible paths plus some impossible paths; the paths that are not mapped are all impossible). This is not the same as solving the halting problem. You can construct a finite-state machine based on the branch points, and then use this to say if a particular path from a given point in the code to another point is potentially possible (i.e. potentially legitimate) or impossible (definitely illegitimate). Note that you *can't* say (in general) if a given point in the code will ever be reached, which is the equivalent of the halting problem.

    3. Re:Looks like something AV has done for a while by Delkster · · Score: 1

      Very true. Good point. I didn't come to think that they'd want to allow impossible paths, but then, why not...

  31. Re:LINUX has viruses, not as many, like usercounts by LingNoi · · Score: 1

    You link to some random asshat (probably yourself) who links to a dead link. Nice try.

    Sorry to blow your illusion, but that's just pathetic.

  32. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    Per my subject-line? Linux does INDEED, have viruses (no immunity, sorry to blow your 'illusion'):

    Sorry, but how fucking retarded are you?

    Lets ignore the fact that this was posting on 1st April. No, lets look at the article in question..

    When you visit the effected web page the virus on the server uses the memory hook to find the connecting computers mac address and transports itself via udp over any open port.

    Did you even read this or are you so desperate to prove your point that you googled and pasted in any article you could find to prove your point?

  33. Re:Bullshit by Draek · · Score: 1

    1. Linux has no viruses. Why would we need something like this?

    Because Linux has vulnerabilities which can be (and have been in the past) used to take control of a system, and this is an attempt to fight that. All viruses are malware but not all malware are viruses.

    2. If they're going to make a list of the behaviour of _every_ program, then that list would be HUGE, and take petabytes. A blacklist is a lot easier to make and keep up.

    Unless I'm mistaken, this only needs a whitelist for the software installed on the system, so itwon't be that big and a whitelist is safer from a security point of view (uptime may be problematic, though, depending on the number of false positives).

    3. This still wouldn't protect the weakest link: the user. If a virus asks the user :" Add IAmATrojan.exe to the whitelist ", a lot of people wouldn't do it. Heck, if you need even need a normal anti-virus, you're to stupid to work with computers.

    Because this is primarily aimed at servers, and if someone with access to your server's whitelist is clueless enough to fall for that, you have *MUCH* bigger problems than a piece of malware, believe me.

    --
    No problem is insoluble in all conceivable circumstances.
  34. Re:Bullshit by QuoteMstr · · Score: 1

    "Malware" is an unfortunate choice of words here.

    While desktop Linux doesn't have the same malware problems as Windows, we still have problems with random server programs being compromised. This approach is actually, I think, more effective on the server than the desktop.

    Firefox, say, has a much larger variety of behavior than bind. Firefox can do anything; bind does the same thing over and over and over.

    Since Firefox does more varied stuff, this system call profiling approach would see more of its behavior as "normal". But because bind does the same thing over and over, almost every behavior is outside that norm, and would be caught.

  35. Re:LINUX has viruses, not as many, like usercounts by RiotingPacifist · · Score: 1

    while you are true that there are viruses for Linux and it is a smaller target, they are not JUST as vulnerable, the entire UNIX base (small programs that do little and user privilege restrictions) make UNIX systems much more secure from the start. Its also pretty much impossible to infect a well secured system (SELINUX + PAX + hardened toolchain) and this seams like an extra layer to provide automated selinux-like functionality.

    --
    IranAir Flight 655 never forget!
  36. glibc calls setuid(2) by alba7 · · Score: 1

    So what can you say about programs using glibc? What if innocent functions like fopen(3) call setuid(2)? What if they do it only after an update of glibc?

    --
    Post tenebras lux. Post fenestras tux.
    1. Re:glibc calls setuid(2) by Anonymous Coward · · Score: 0

      Sounds like someone trojan'ed glibc then...

  37. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    I did, and noted it was from 2007, on my first posting, & 2003 in my second one from SECUNIA... showing there are, indeed, virus/worms etc. et al for Linux also (UNIX and MacOS X as well).

    That utterly refutes the intial poster's stating "THERE ARE NO VIRUSES FOR LINUX"... putting it bluntly? That's horsecrap.

    The second post of mine also merely aids in refuting what the replier stated, showing evidences/the presence of 40 KNOWN viruses for Linux, AS FAR BACK AS 2003 in fact (& they did not just "go away" & probably indicate that there are actually more, NOW).

    AND, my citing is from a very reputable site in the area of security, in SECUNIA.COM...

    Again, which, indeed states that there are viruses for Linux, period!

    (So thus, the 'puny old trick of that is stale information' on your part? Doesn't change a thing, period!)

    Better luck next time Linux penguins, in spreading around yet more "F.U.D." like usual.

    APK

    P.S.=> What "blows me away", is that so many of you Linux 'zealots' can't accept reality... especially that the very reason your OS does not take the "top spot", especially on the end-user desktop, is imo, because you don't have the wealth of wares for the sheer variety of purposes that users want, productivity apps to games, that Windows enjoys... as well as the sheer abundance of device driver & hardware support Windows has as well! apk

  38. "the kernel in the system's operating system"? by Karellen · · Score: 1

    WTF?

    --
    Why doesn't the gene pool have a life guard?
  39. Systrace by RAMMS+EIN · · Score: 1

    This actually isn't new. Systrace has been doing this for years. And it runs on more than just Linux.

    --
    Please correct me if I got my facts wrong.
  40. If we don't complain, they won't improve by pjt33 · · Score: 1

    you could always do something crazy like read the article.

    Just stay by your computer and the men in white coats will be with you shortly.

  41. Tron by nsayer · · Score: 2, Interesting

    Somehow, this technique reminds me of the (obviously rather simplistic) description of the functionality of the Tron program from the movie of the same name. From the script:

                        DILLINGER
      [...]
                                            What's the thing you're working on?

                                                                    ALAN
                                            It's called Tron. It's a security
                                            program itself, actually. Monitors
                                            all the contacts between our system
                                            and other systems... If it finds
                                            anything going on that's not scheduled,
                                            it shuts it down. I sent you a memo
                                            on it.

                                                                  DILLINGER
                                            Mmm. Part of the Master Control Program?

                                                                  ALAN
                                            No, it'll run independently.
                                            It can watchdog the MCP as well.

  42. Cylant Secure by Anonymous Coward · · Score: 0

    This sounds just like Cylant Secure which was released in 2002. I believe that the company is defunct now, though. They had a profiling system built into the kernel that you trained with normal behaviors and then put in secure mode. If anything deviated from that profile various actions could be taken like halting a process or adding the offender to a blacklist/firewall rule. In particular it profiled the network stack and system calls.

    I should mention that I was the college student who wrote the prototype system that was spun off into the commercial venture that became Cylant Inc.

  43. As I understand it by slimjim8094 · · Score: 2, Insightful

    this isn't anything specifically to do with malware.

    As far as I can see, this verifies that the binary currently running is the same binary that was compiled from a (trusted) source.

    When you compile it, it knows (from the source) what the program will and won't do. If the program deviates from that, it dies (as it's been replaced by malware, presumably)

    If I'm wrong, please correct me...

    --
    I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
    1. Re:As I understand it by Anonymous Coward · · Score: 0

      explain to me why they need it then?

      Don't we already have a mechanism to send a "signal" to "kill" a process which exceeds its own limited address space?

      Don't we have a system by which we can deny a program "permission" to be run under certain accounts and alter certain information?

      Sounds like they're re-inventing the wheel.

  44. Aren't AV vendors just trying a marketing push? by SMOKEING · · Score: 1

    All the gibberish about "viruses for linux" and such self-same security matters...

    Excuse me, I don't quite get it. A Linux system is as secure as the admin wanted or cared it to fasten. Period.

    If/once bad guys have managed to meddle with it in whatever way, there is no use killing this or that seemingly misbehaving app; there is only one way to rectify matters, and that is, pull the power cord and call the admin in and have him inspect the matter. A particular, named human is in charge here, not a "vendor" nor a contracted third party.

    At this point I wonder, if the very subject matter of the article and the research at large it underlies, is just a marketing push of AV companies to plant a foot where there's no foothold for them? They all belong and flourish in "Windows ecosystem", where they enjoy the same rights as malware proper. Why introduce them both in Linux?

  45. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    "while you are true that there are viruses for Linux and it is a smaller target, they are not JUST as vulnerable, the entire UNIX base (small programs that do little and user privilege restrictions) make UNIX systems much more secure from the start. Its also pretty much impossible to infect a well secured system (SELINUX + PAX + hardened toolchain) and this seams like an extra layer to provide automated selinux-like functionality." - by RiotingPacifist (1228016) on Sunday September 28, @04:45PM (#25186999)

    Agreed on their being viruses for Linux, just not as many because it is not as targetted (for the reasons I stated in my first post most likely)...

    AND?

    On SeLinux & hardening?? You're correct... &, additionally, I hear you about SeLinux (or other tools like AppArmor in other Linux distros as well), but...

    I.E., as far as SeLinux? Well - It appears that generally YOU yourself, have to USE IT, manually, & set it up (much like SCW for Windows Server 2003)... &, just like security-hardening Windows it seems, there is some manual labor involved!

    See the 1st page of that URL below in fact, for some proof thereof:

    ---

    Evidenced by a posting I have done for Windows users in fact, late last year, as to "security hardening" Windows (&, even an SeLinux bearing distro, SuSe Enterprise):

    HOW TO SECURE Windows 2000/XP/Server 2003, & EVEN VISTA, plus, make it "fun-to-do", via CIS Tool Guidance (&, more):

    http://www.tcmagazine.com/forums/index.php?s=00c84096252cd4648befe541d41ecf9d&showtopic=2662

    (Currently, iirc, since Dec. 2007, this one has gained over 200,000++ views worldwide, & additionally got me paid via winning PCPitStop's monthly tech posting contest, for January 2008... it works!)

    I say this, because, it has been tested via numerous others using it & months later stating they AND THEIR CLIENTS'systems, even that of kids & teens, no less, which have not been infected/infested, since this guide's points were applied!

    Screenshots ARE there, from one of your members here in fact no less, as regards an SeLinux bearing distro, in SuSE Enterprise edition iirc!

    On SeLinux bearing distros even?? Once more - Apparently, to gain its FULL functionality, & harden Linux via SeLinux usage, for yourself... it's some work!

    (In fact/again - Evidence of that from one of your own here (Bert64) is there, using SuSe Linux (an SELinux bearing distro) showing by default? Linux doesn't score any better than Windows does (46/100 scores) by default... HOWEVER - "security-hardened" though? BOTH Windows & Linux can gain 90++/100 range type scores!)

    Yes, sure - Comparing "Apples to Oranges", in diff. OS' yes, but the point IS there... That they BOTH are relatively "open/unsecured" out-of-the-box, oem-stock, is the MAIN thrust/point of my statements here in my reply to you!

    ---

    It is a guide I have been building steadily onto since 1997 in fact, for Windows users... an outgrowth of my first article online in "Article #1" over @ NTCompatible.com, & this is is CURRENT 'evolution'...

    It deals mainly in how to SECURE (&, even speed up) Windows, & it has been quantified via CIS Tool!

    (I have been improving each year I discover more & new ways to do so in fact, & tested via the multiplatform CIS Tool (which runs on variants of *NIX as well, inclusive of Solaris, BSD-variants (no MacOS X version yet though, sorry), PLUS Linux distros))

    ---

    The exact SAME can be done for Windows, as SeLinux can do (via SCW for instance, or Microsoft Baseline Security Analyzer + other tools native to the OS, such as Registry &/or FileSystem ACL's & more)... and, Linux (even SeLinux &/or AppArmor bearing distros) is NOT as well secured out of the box, oem-stock, as you may think - proof of this is below

  46. Re:Bullshit by somersault · · Score: 1

    if you need even need a normal anti-virus, you're to stupid to work with computers.

    What if you want to download a freeware program to perform a task, but want to know if it's infected? What if your system has a zero day exploit and has been infected without you knowing? Anti-virus scanners are unfortunately a necessity when it comes to using pre-compiled binaries.

    If you are never going to connect to the net or removable storage, and only use software that you have written yourself, then yes - anti-virus is unecessary

    --
    which is totally what she said
  47. Old news by Anonymous Coward · · Score: 0

    I reviewed a product that was designed to do exactly this back in the summer of 2002. Couldn't get it to work properly. The review (which I can't find a link to at the moment) appeared on linux.com in the summer or fall of 2002. I think the company which made it was based out of Florida.

    Strange seeing this came back up again after six years.

  48. Pre-Cybercrime? by JackassJedi · · Score: 1

    Maybe this sounds stupid, but in a weird way this reminds me of this little project here, and I think it is the wrong approach, no matter the subject. It might work better on a computer system because a lot can be predicted, complexity is simpler but i can see the same kind of false positives occuring with this system as well.

    The consequences of course have a different quality of impact, this isn't dealing with human lives, but there still might be a lot at stake.

    --
    Power corrupts the few, while weakness corrupts the many.
    1. Re:Pre-Cybercrime? by Eskarel · · Score: 1
      As has been stated before, false positives would be very unlikely in this scenario, if the program does something that doesn't match the execution pattern in its source code then its done something wrong.

      False negatives would be a much bigger problem, but it's as good an automated technique as anything I've seen before. If the profiles can be distributed with binaries it might make it mainstream.

  49. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    http://linux.slashdot.org/comments.pl?sid=978861&cid=25186999

    Others who are Linux fans agreed there are LINUX viruses also, see the URL above... &, if that is not proof enough...?

    It's ENTIRELY possible your DNS server hasn't fully cached or resolved the URL I posted above, which is why you cannot see it, or you are using some form of blocking locally on that URL, such as a HOSTS file entry!

    (However, as the URL above notes? Others apparently saw it though, & even admitted the existence of viruses on Linux also)

    Take your pick, but... either, you are just so "loathe to admit it" that there are viruses on Linux, you are just playing games.

    Either way? It seems your are outnumbered, outgunned, & have to eat your words (that there are NO LINUX viruses, & sorry... there are! Less than on Windows, but... they are there (which makes sense - Linux users are less targetted for many reasons, I listed some possibles in my init. post in fact))

    APK

  50. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    "Sorry, but how fucking retarded are you?" - by Anonymous Coward on Sunday September 28, @04:20PM (#25186783)

    Ok, evidently? Not as "retarded" as yourself (it's either THAT on your end, or, you are just "loathe to admit it") so...

    HERE IS A FAIRLY RESPECTED WEBSITE IN REGARDS TO LINUX VIRUSES, in SECURITYFOCUS.COM, & their statements on this issue:

    http://www.securityfocus.com/columnists/188

    SALIENT QUOTE:

    "There are about 60,000 viruses known for Windows, 40 or so for the Macintosh, about 5 for commercial Unix versions, and perhaps 40 for Linux"

    I guess because I can find something you do not like, & make you look quite assinine in the doing of it, I must be 'retarded', eh? I wonder who really is, now, @ ths point??

    APK

  51. Re:Bullshit by robo_mojo · · Score: 1

    What if you want to download a freeware program to perform a task, but want to know if it's infected?

    Run it under a dummy user account.

    What if your system has a zero day exploit and has been infected without you knowing?

    Anti-virus doesn't protect you from zero-days either. If you want to check for infections, your best bet is to use some kind of tripwire software (with signed hashes stored and checked offline).

    Anti-virus scanners are unfortunately a necessity when it comes to using pre-compiled binaries.

    Then don't use pre-compiled binaries. Or like I mentioned above, use dummy accounts. Or try out the different tools for limiting system access (selinux, etc).

  52. What about plug-in based systems? by JSBiff · · Score: 2, Insightful

    How does this thing deal with plug-in/add-on based systems like Firefox or Eclipse, where new capabilities get added to the executable through dlls (or java classes, I guess, in the case of Eclipse? - Although, with regards to Java, I wonder if this system would work at all, since I think the kernel never exactly 'sees' Java programs or classes as executables, but only the JRE, which already has all the system calls built into it?)

    1. Re:What about plug-in based systems? by Jerry+Smith · · Score: 4, Informative

      How does this thing deal with plug-in/add-on based systems like Firefox or Eclipse, where new capabilities get added to the executable through dlls (or java classes, I guess, in the case of Eclipse? - Although, with regards to Java, I wonder if this system would work at all, since I think the kernel never exactly 'sees' Java programs or classes as executables, but only the JRE, which already has all the system calls built into it?)

      It's about servers here, I personally think one should really think thrice before installing plug-ins and add-ons on a server, and rather go browsing on a desktop machine. Regarding Java, I can see your point.

      --
      All those moments will be lost in time, like tears in rain. Time to die.
    2. Re:What about plug-in based systems? by Anonymous Coward · · Score: 0

      Are you completely unfamiliar with Apache, or do you just not understand how the module system works? Apache is utterly useless without plugins.

      dom

    3. Re:What about plug-in based systems? by Jerry+Smith · · Score: 1

      Are you completely unfamiliar with Apache, or do you just not understand how the module system works? Apache is utterly useless without plugins.

      dom

      I was referring to Firefox, but yes: Apache would have quite few uses without plugins. I have some knowledge of modular systems, and I do hope that Apache will continu to function as expected in the proposed approach.

      --
      All those moments will be lost in time, like tears in rain. Time to die.
  53. Aready done somewhere else? by Anonymous Coward · · Score: 0

    It seems to me this is really close to what SysTrace does on BSD system for years. It is quite surprising that Linux did not had such a defense already.

  54. Re:LINUX has viruses, not as many, like usercounts by howlingmadhowie · · Score: 1

    the article continues to say that those 40 have never been seen in the wild because they were research projects. it then links to a webpage called WildList, claiming that some viruses for Linux (sic) are mentioned there. the article is from 2003. i've been browsing WildList for the last 15 minutes, working my way back through 2008 and 2007 and have yet to find a virus for Linux (sic).

    face it, there aren't any gnu/linux viruses in the wild, despite the fact that gnu/linux has a majority share of webservers---exactly those computers you would most like to infect.

  55. nah by Anonymous Coward · · Score: 0

    It will just start answering your viagra spam.

  56. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    The 2007 link is 4/1/2007, you moron.

  57. Automatic. Re:selinux by leuk_he · · Score: 1

    The users who trains the model has to be knowledgeable. That is the same requirement as selinux. I should be possible to make SElinux trainable too(maybe there is software that already does that, I never checked), but you still need experts users who understand what an application does on OS level.

    This kernel plugin is a kind of tripwire on steroids.

  58. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    "The 2007 link is 4/1/2007, you moron." - by Anonymous Coward on Monday September 29, @03:37AM (#25191433)

    A RESPECTED WEBSITE (AS REGARDS LINUX VIRUSES), in SECURITYFOCUS.COM, & their statements on this issue:

    http://www.securityfocus.com/columnists/188

    SALIENT QUOTE:

    "There are about 60,000 viruses known for Windows, 40 or so for the Macintosh, about 5 for commercial Unix versions, and perhaps 40 for Linux"

    I am correct, you are not, & are ranting like a frustrated spoiled child now on your part... hilarious!

    APK

    P.S.=> Reduced to "name calling" on your part I see, lol: That is about all you have, which is nothing... apk

  59. Mod parent up by marcosdumay · · Score: 1

    That is the second time I see someone complaining that it won't work on scripts, and the parent is a very well constructed answer to that.

  60. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    Red Hat, Fedora Servers Compromised:

    http://linux.slashdot.org/article.pl?sid=08/08/22/1341247

    "gnu/linux has a majority share of webservers" - by howlingmadhowie (943150) on Monday September 29, @02:49AM (#25191245)

    LOL, at this point, judging by your spinmaster tactics so far? I suppose you're going to try to tell us all now that "LINUX SERVERS ARE INVULNERABLE", right? It seems even the "horses' mouths" in their distro makers can't make it so...

    PLUS - The ONLY reason THAT Linux servers are more used, is because it is cheap...& businesses don't like to spend.

    Linux zealot: Additionally, You can try to put ANY KIND of "spin" on it, but others know there are viruses for Linux, such as SECURITYFOCUS.COM noting it, & even evidenced that for me... so much for your "spinmaster tactics"!

    QUESTION: Does javascript run on Linux? Do WebBrowsers & Email Programs run on Linux?? Are WebBrowsers & Email Programs subject to using javascript to foist exploits on the machines they run on???

    ANSWER: YES to all of the above.

    (Thus, Linux can be "hit" by the same type of things you see happening to Windows, period, as well!)

    Nobody attacks Linux because there aren't enough users to make it worthwhile mainly.

    E.G.-> If you're a botnet master you go after the LARGEST BLOCK OF POSSIBLE USERS so you have a large body of zombie machines you can control (so you can, say, DDOS other systems via those controlled machines, & the largest block of users out there use Windows because it has more softwares for any conceivable purpose, and more hardware/driver support for more hardware, period!)

    APK

    P.S.=> You guys are hilarious... you really are. You CAN'T STAND your OS of choice is in "last place" (not that it's horrible, it's not, but... apparently, it's "2nd rate" in the view of those in the world out there using softwares daily on the job on their workstation desktop, or, at home (where it matters most on the latter 2, & why is that, I wonder?))... apk

  61. FOLLOWUP, & A QUESTION... apk by Anonymous Coward · · Score: 0

    "while you are true that there are viruses for Linux and it is a smaller target, they are not JUST as vulnerable" - by RiotingPacifist (1228016) on Sunday September 28, @04:45PM (#25186999)

    QUESTION(s): Does javascript run on Linux? Do WebBrowsers & Email Programs run on Linux?? Are WebBrowsers & Email Programs subject to using javascript to foist exploits on the machines they run on???

    ANSWER: YES to all of the above.

    (Thus, Linux can be "hit" by the same type of things you see happening to Windows, period, as well!)

    The "DOM" (document object model) used IS the weakness here, really!

    ( & iirc, it's not any diff. regarding javascript (the largest used 'attack vector' there is, & you can verify this by the root cause of MOST of the attacks out here for the past 1-4 yrs. now, even in bad adbanners having this happen, @ a spot like SECUNIA.COM in fact) on Linux than it is on Windows).

    "the entire UNIX base (small programs that do little and user privilege restrictions) make UNIX systems much more secure from the start. Its also pretty much impossible to infect a well secured system (SELINUX + PAX + hardened toolchain) and this seams like an extra layer to provide automated selinux-like functionality. - by RiotingPacifist (1228016) on Sunday September 28, @04:45PM (#25186999)

    IF you read the URL article I put up in my first reply to you, then, you'd see the same type of tools exist for Windows, such as automators like SCW (security configuration wizard on Windows Server 2003 for example) &/or MBSA (Microsoft Baseline Security Analyzer), as well as built-in tools for fine-grained permissions to files/folders etc. called ACL control.

    (in fact, it's said that on Windows? Even BETTER ones exist, & especially @ the "ACL" level than exist on *NIX's in general by default... Especially by default (distros w/out AppArmor OR SeLinux), especially in regards to 'fine grained permissions' for file/folder/object accesses (analog on LINUX is MAC (mandatory access control), iirc)

    APK

  62. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    That makes sense. Thanks to Microsoft, most if not all linux zealots are already paranoid thinking someone is out to get them. Read any MS story and you see the zealots shit their collective pants trying to come up with new spin for the newly indoctrinated to lap up and hate MS. But theres a silver lining, You wont see them run any random executable or open some random email with a nice payload. Which is good because it keeps the community safe and also when explaining any shortcomings of linux you can just blame evil MS. Its a win/win. A bit cultish for my taste, but hey whatever floats your boat.

    http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems

    The 40 viruses are expected given the miserable market share. Note that this is not the 'good' kind of low market share, like lamborghinis.

  63. Re:LINUX has viruses, not as many, like usercounts by Anonymous Coward · · Score: 0

    Microsoft isn't "evil", they're in business, to MAKE MONEY... a nice side effect is that they DO improve their product line, because of OS' like Linux improving, imo @ least (as well as Ms' own impetus to do so).

    I agreed on the "shart of market", in regards to how often an OS gets attacked, in my initial posting in fact, do refer to it, if need be on your end.

    &, it makes sense!

    I.E.-> Why on earth would a botmaster, for instance, want to seize the LEAST used OS there is, which would yield up the least possible # of 'zombiable' rigs... & which generally has "saavy users" (more techie types) who can most likely easily ID it, if not kill it, & possibly even attack the one doing the controlling?

    They WOULDN'T, & would avoid it, like a plague, for all of the reasons noted.

    (CONVERSELY, most folks that use Windows do so, because it is easier (less tty terminals work etc., more wizardy control interfaces, vs. playing around in arcane config files in etc or usr/home et al), & they're less "techie" most of the time, so, it gets attacked the most - as well as their being more Windows users out there period, thus, more possible "zombied rigs" attackable, easily, w/out retaliation as well))

    APK

    P.S.=> Now, were Linux the #1 most used OS there is? You can BET YOUR BOTTOM DOLLAR, it'd be under the type of level of attacks that Windows is... it just makes sense! Mainly, imo @ least? Because the javascript DOM is in place on Linux, in its email programs &/or webbrowsers too... & THAT? That is the #1 most used attack vector present today, thus, it'd be JUST AS DOABLE, TODAY, ON LINUX, as it is on Windows, today... apk