Why no antivirus or online scan for Linux?

Discussion in 'other anti-virus software' started by rpk2006, Feb 11, 2020.

  1. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    I agree. There are still countless applications and tools for Windows installed by many users which are not automatically updated. Not so on Linux unless the users installs software from outside the official repositories which is normally not necessary.

    @142395 : You provided some very old sources as evidence (I haven't read those Japanese sources yet as I don't use Google Translate on principle). But if you follow Kees Cook's blog you'll see that a lot of important improvements in that area have been added in the past 2-3 years or so. And if it comes to package hardening this post shows that a lot of progress has been done in the past years as well.
     
  2. 142395

    142395 Guest

    Makes sense, tho I don't count that as security and instead take it as convenience as mentioned. I haven't encountered anyone who disabled auto-update even when I helped to remove malware on a system. Most malware nowadays come from user installation.
    At least many of most-targeted software on desktop are still written by native code. But TBH I also don't focus much (except as a hobby) on memory mitigation and much prefer Linux' isolation approach, but that's just my preference - I separate facts form my view, or at least trying to do so always.
     
    Last edited by a moderator: Feb 20, 2020
  3. 142395

    142395 Guest

    "That's old" argument only makes sense if there's really a sign of change. As I said, they've been investigating quite long years and there's no sign of rapid change (BTW replaced a link w/ a bit newer one, as I've found it's also publicly available). Having glanced at your links, there seems to be no big news - I'm ofc aware of kernel lockdown, Clang CFI, & KASLR (*) but all the rest are more of tiny changes - if you count such changes too, Windows also has more than twice improvements as I said. But what matters is not the number, rather how they work.

    [EDIT] too bad, a link to various technologies added to Windows 8 seems to be dead: http://blogs.technet.com/b/srd/arch...tigation-heap-corruption-vulnerabilities.aspx
    Okay, available on WM: https://web.archive.org/web/2017111...e-mitigating-heap-corruption-vulnerabilities/
    But I thought there was a more comprehensive PDF, so it's not what I was seeking for.

    (*) The first one is more about isolation. The latter two are more of evidences that Linux is behind, as Windows were quicker to adopt equivalents of those (yes, not only ASLR but also KASLR which was introduced in v3.14).
     
    Last edited by a moderator: Feb 20, 2020
  4. 142395

    142395 Guest

    [This is just a personal opinion.] If you only follow one platform/software, there can only be improvements - it's so obvious. You only see things once you started to see and compare w/ other platforms. I've been Linux user since Ubuntu 9.04 and Windows user since Vista (in strict sense - I've used XP too, just haven't owned any XP machine), and I don't see anything on security has changed that rapidly in these 2-3 years on either platforms despite I now understand these staff much more than past, at least anything over what are naturally expected by technological and environmental changes. But if I take 10+ years scale, it seems while Linux has been steady, Windows has changed dramatically from a terrible state to an acceptably-secure state.
     
  5. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    Well, I don't think that this is correct. Since the Kernel Self-Protection Project was established quite a number of patches originating from grsec/PAX have been added to the Linux kernel in the past years. (EDIT: I counted about 30 of those patches since kernel 4.30).

    Exactly, and that's certainly hard to evaluate in a couple of sentences in this forum.

    So? There are multiple heap corruption/overflow mitigations in Linux as well, and new ones have been added in the past years (search for them, e.g., in the above mentioned blog):

    Not quite correct. ASLR was introduced in 2005 already (although it was weaker then).

    Okay, this discussion leads to nowhere. As you said yourself: "Windows & Linux memory managements are completely different so SIMPLY comparing mitigation is impossible and nonsense."
     
  6. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    There not much of anti-virus (except the ClamAv that you mentioned) software
    for Linux because most viruses are simply made for windows

    https://www.av-test.org/fileadmin/pdf/publications/security_report/AV-TEST_Security_Report_2015-2016.pdf

    According to this there were around 600 million Windows only malware floating around in 2016, 67% of all detected malware.

    Android had around 7% and Linux only 0.02%
    But because Android is Google modified Linux one could say that 7,02% of malware in 2016 were for Linux only.

    In old days Windows security was a joke and remained a joke all the way till W10. So now W10 and ordinary vanilla Linux distro security are about the same.

    But I would still love to see malware that can penetrate fully security hardened Linux distro (grsecurity + all userland compiled as PIE/PIC + Full Relro + stack smashing protection) .....
    IMHO, only firmware level (like ME in Intel) malware could bypass that but then it could bypass any OS ...

    As a side note .....
    It's also interesting to note that normal security model is level 0 to level 3 "rings" (where ring 0 is kernel, rings 1- 2 drivers and ring 3 for application). The lower the ring number the more privileges the running stuff has.

    However, that's not the whole truth...there are three more rings below 0 (-1 to -3)

    Ring -1:
    If CPU supports Intel VT-x or AMD-V then it has few instructions that work below kernel level 0,
    ring level -1.

    Ring -2:
    SMM (System Managment Mode), every x86/x86_64 CPU had that since 1993.

    Ring -3:
    Any x86_64 CPU that has additional ME co-processor (practically all Intel CPUs since 2006 and all AMD CPUs since 2013).
     
    Last edited: Feb 20, 2020
  7. 142395

    142395 Guest

    KASLR is different from (application) ASLR. In both cases Windows was quicker.
    That's not meant to imply discussion is impossible and just a confirmation about a fact anyone who knows very basics of programing and exploit on each platform knows, so I emphasized "SIMPLY".
     
    Last edited by a moderator: Feb 20, 2020
  8. summerheat

    summerheat Registered Member

    Joined:
    May 16, 2015
    Posts:
    2,199
    I know. But you mentioned both in one sentence ... but perhaps I misunderstood.

    Btw., ALSR was introduced in Windows Vista (according to several sources) and that one was released in 2007, i.e. later than the (weak) implementation in Linux. ;)
     
  9. 142395

    142395 Guest

    As explained in the link of my post, that weak form didn't make much sense against real exploit, and Vista-like ASLR was late. Also consider delay for the kernel to be adopted by mainline distros. But sure in literal sense I was wrong.

    [EDIT] Ah, well, not on the link. I'm sleepy lol.
     
  10. 142395

    142395 Guest

    BTW I have to say the graphs in the Cook's blog are what are very expected. The thing is overall improvement rate is not changing at all. If you think "But IB and PIE is rapidly improving these years!" you simply don't understand what these means - PIE for example has performance impact (particularly on x86) and not very effective on x86 platform, these must be the reason the adoption rate had been noticeably low (you see other mitigation were more rapidly added in both Debian & Ubuntu), but since now most platform are 64bit and hardware are more powerful, it's time to widely adopt this mitigation, if not too late. As he said some mitigation which are not on the graph have been added meanwhile, and I'm 99% sure their adoption rate is very very low, given past practice. Those major distro have never caught up the latest security status of Linux kernel.

    @Stefan Froberg
    I didn't know about -1 ~ -3, thx for the info.
     
    Last edited by a moderator: Feb 20, 2020
  11. 142395

    142395 Guest

    Having read the first page of the blog @summerheat posted (so covers from Sept. 26, 2016 to now), found out there are really not many important things to the discussion. Almost all the contents were classified to (examples are just examples, and there are many overlaps tho I won't explicitly write them for simplicity):

    - not about memory ACE mitigation: tho bug-check at compile may be regarded as indirect mitigation and some info leak prevention and isolation too
    e.g. kernel lockdown, boot entropy improvement, Microarchitectual Data Sampling mitigations on x86, temporary mm for text poking on x86, LSM stacking: shared security blobs, SafeSetID LSM, spectre v2 userspace mitigation, L1TF, protected regualr and fifo files, trusted arthitecture-supported RNG initialization, Jailhouse hypervisor, syscall register clearning x86, Kernel Page Table Isolation, retpoline, %p hashing, improved boot entropy, seccomp improvements, CONFIG_FORTIFY_SOURCE, LSM structures read-only, structleak plugin, seeding kernel RNG from UEFI, Latent Entropy GCC plugin, User namespace restriction, gcc plugin infrastructure, LoadPin LSM, CONFIG_IO_STRICT_DEVMEM, strict sysctl writes, Ambient Capabilities

    - more of fixing problematic or incomplete implementation of past: they shouldn't be counted as true improvements
    e.g. what the author call the department of "how did this go unnoticed for so long", implicit fall-through removal, explicitly test for userspace mappings of heap memory, stack variable initialization includes scalars, jump labels read-only after init, shift overflow helper, MAP_FIXED_NOREPLACE, pin stack limit during exec, series of 'Variable Length Array removals', struct timer_list refactoring, lower ELF_ET_DYN_BASE, Expand stack canary to 64 bits on 64-bit systems, random_page() cleanup, x86 32-bit mmap ASLR vs unlimited stack fixed, ptrace fsuid checking, x86 W^X detection

    - does not make exploit very hard by itself or limited in scope: only useful in specific condition or technique
    e.g. ld.gold support removed, heap variable initialization, stack variable initialization with Clang, setuid-exec stack limitation, NULL-prefixed stack canary, linked list hardening, hardened usercopy, zero-poison after free, x86_64 vsyscall CONFIG; 'page allocator freelist randomization', 'removing open-coded multiplication from memory allocation arguments', 'set_fs() balance checking', 'Expanded stack/heap gap', 'read-only usermodehelper', 'SLUB freelist hardening', 'SLAB freelist ASLR', 'eBPF JIT constant blinding', & 'read-only after init' only make sense for kernel exploit

    - only for specific hardware:
    especially those for ARM won't make sense for most desktop user, they are mostly for Android; those for newer gen high-end Intel CPU make sense but I guess not a few ppl install Linux on low-end or older PC/laptop
    e.g. tagged memory relaxed syscall ABI, x86 CR4 & CR0 pinning, Intel TSX disabled, Kernel Userspace Access Prevention on powerpc, most itmes on v5.0 & 4.10, per-task stack canaries powerpc, Sparc ADI, execute-only memory for PowerPC, NX stack and heap on MIPS, CONFIG_CPU_SW_DOMAIN_PAN

    - same or similar is already implemented on Windows:
    e.g. Clang CFI, x86 execute-only memory

    - strictly not a security thing:
    e.g. hardware security embargo documentation, Kconfig compiler detection, security documentation ReSTification, CONFIG_DEBUG_RODATA renamed to CONFIG_STRICT_KERNEL_RWX, seccomp coredumps

    What are left as "a bit interesting":
    - unprivileged userfaultfd sysctl knob
    - allocation overflow detection helpers
    - automatic stack-protector
    - refcount_t overflow protection
    - vmapped kernel stack and thread_info relocation on x86
    - ASLR entropy sysctl

    but they're not as innovative nor significant as DEP, ASLR, or CFI. Despite many bypasses found later, these three required fundamental and general changes for attack and significantly raised the bar - in fact current attacks are not as reliable as in past and harder to fully automate. So I don't think I need to change any of my conclusion, IOW there's no evidence that Linux excels in memory mitigation and improvements in this area are steady as in the past - you can't see forest while seeing a tree. I don't believe those implementation inspired by or ported from PaX/GRsec only started by KSPP. Indeed, as early as 2009 Linus said "Much of it did get merged over the years". They just didn't take explicit forms. I'm not sure to continue to the second page, but don't expect sudden change. I already explained why Windows excels in memory protection, but elaborating a bit, not only Windows allows you to control application of various mitigation w/out compile by yourself, if all ACG, CIG, and strict CFG are applied (programs supporting all of them are so far few, while CFG support is no more so rare e.g. all Electron apps) bypassing it is quite hard while only semi-standard CFI for Linux application is Clang options and there are known bypasses for it (1) - note even w/out the strict option a number of known bypasses of CFG including BATE have been fixed. This paper analyzed and compared various CFI technologies including CFG & RAP, but didn't directly include Clang CFI (mentioned in Discussion tho). Anyone who has been following evolution of exploit techniques will understand the lack of CFI is significant but it appears on popular Linux currently only browsers are compiled w/ CFI enabled (probably there are a few others, just I couldn't find) as application software.

    I'm not saying Windows is more secure than Linux (2). When security models are different comparing them is apple and orange, but if you focus on a certain aspect, comparison is possible. I did it for memory mitigation as an example to counter the argument "Linux is so secure by default that you don't need AV", as I believe correct one is "Linux has different security model which doesn't work well w/ AV".

    @reasonablePrivacy In the end scripts need to be interpreted and thus can not be free from vuln like UAF if the interpreter has the vuln.

    (1) Comparing this old blog w/ the latest official document and searching at llvm.org, it seems there has not been much changes made on function of Clang CFI, except for bug fixes. I also note they naturally linked to a M$ site.
    (2) You can find a number of criticisms I made for Windows in this forum.
     
    Last edited by a moderator: Feb 23, 2020
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.