Slashdot Mirror

← Back to Stories (view on slashdot.org)

New NetSpectre Attack Can Steal CPU Secrets via Network Connections (bleepingcomputer.com)

Posted by msmash on from the furthering-their-reach dept.

Scientists published a paper Friday detailing a new Spectre-class CPU attack that can be carried out via network connections and does not require the attacker to host code on a targeted machine. From a report: This new attack --codenamed NetSpectre -- is a major evolution for Spectre attacks, which until now have required the attacker to trick a victim into downloading and running malicious code on his machine, or at least accessing a website that runs malicious JavaScript in the user's browser. But with NetSpectre, an attacker can simply bombard a computer's network ports and achieve the same results. Although the attack is innovative, NetSpectre also has its downsides (or positive side, depending on what part of the academics/users barricade you are). The biggest is the attack's woefully slow exfiltration speed, which is 15 bits/hour for attacks carried out via a network connection and targeting data stored in the CPU's cache.

63 comments

  1. donâ(TM)t keep your secrets in the cpu duh by Anonymous Coward · · Score: 0

    keep them in your pants

    1. Re:donâ(TM)t keep your secrets in the cpu duh by Anonymous Coward · · Score: 0

      Duh. That is where I keep the glockenspiel.

    2. Re:donâ(TM)t keep your secrets in the cpu duh by Anonymous Coward · · Score: 0

      For ARM it's 1 bit per hour.

  2. 2.5 years later... by Anonymous Coward · · Score: 0

    I've successfully exfiltrated MARIO.NES

  3. Easily blocked with correct network config by Anonymous Coward · · Score: 1

    This is not news... just set up your network correctly and you're golden.

  4. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  5. Only not-vulnerable computers connect to Internet? by Futurepower(R) · · Score: 1

    Which ARM processors are NOT vulnerable to Spectre and Meltdown? What is the fastest cheap computer not vulnerable?

    Maybe only computers with ARM processors should be allowed to connect to the Internet. All other computers in an organization would exchange data using a proprietary system.

  6. 15 bits/hour for attacks by fahrbot-bot · · Score: 1

    Sounds slow and boring. I will definitely wait to see this 007 / James Bond sequel NetSpectre on cable...

    --
    It must have been something you assimilated. . . .
  7. 15 bits per hour by LittlePud · · Score: 5, Insightful

    It looks like a useless exploit for any practical purpose. I highly doubt the contents of a CPU cache would remain static for long enough to extract any information of value.

    1. Re:15 bits per hour by Anonymous Coward · · Score: 0

      The second variant doesn't use cache

    2. Re:15 bits per hour by Anonymous Coward · · Score: 0

      I thought that too while I read it at first, but that isn't true. The likelihood is this would be used to obtain private keys.

    3. Re:15 bits per hour by LittlePud · · Score: 2

      I thought that too while I read it at first, but that isn't true. The likelihood is this would be used to obtain private keys.

      A key (even a short symmetric one) is 128 bits, if not 256 (ex: AES). Public/private keys are even longer at 2048 bits.

      Even at 60 bits/hour, that’s 2 hours minimum to extract a key. Will the cach contents remain unchanged for that long?

    4. Re:15 bits per hour by Anonymous Coward · · Score: 0

      Not for script kiddies. For state sponsored hacking this could actually be useful. Imagine rooting a network switch/router, and then you try to probe high value targets (could be appliance, IOT devices, or servers) on that LAN. Over the course of a few weeks you might actually get something, especially if the targets are running older OS.

    5. Re:15 bits per hour by Highdude702 · · Score: 1

      how long is the data being accessed for, and how often?

    6. Re: 15 bits per hour by link-error · · Score: 1

      What about a VPN router? Eventually, you'd get the full key, just not sure you would know the bit order?

      --
      -Unresolved symbol? Byte me!
  8. Re: donâ(TM)t keep your secrets in the cpu du by Anonymous Coward · · Score: 0

    not a back door, i poop from there

  9. Re:Only not-vulnerable computers connect to Intern by aliquis · · Score: 1

    There was ARM cpus vulnerable for Spectre though.

    But wasn't FX chips free from it?

    Simple (some would had said stupid I guess) enough to not be vulnerable.

  10. Total horseshit by GerryGilmore · · Score: 3, Insightful

    Once you read the pdf describing this, anyone who knows anything can come to the same conclusion. Let's look at the facts:
    1) In order for this or any of the other Spectre/Meltdown "vulnerabilities" (and I use that term loosely, it's really more of a theoretical/lab setup) require you to be running malware on your system. This latest "Net/S/M" calls them "gadgets", but they are fucking malware!
    2) Referencing the basic principles of S/M, basically malware runs a specific set of instructions in a specific sequence to - essentially - tickle the cache by that set/series of instructions to leak some cache data that can then be read by said malware. OK, groovy enough, but how in da hell can you A) know that the cache data you read has not then subsequently over-written by a cache flush on that cache line? and then B) make any reasonable sense out of said data captured? Depending on the size of data gathered, and from what I've read it's pretty tiny, trying to steal "crypto keys" (the big bugbear over at Ars) in this way has to be the most idiotic ever!

    Bottom line: use basic security to keep malware off your system and what does leak through will be much more efficient than S/M, so - worry about the REAL shit, please!

    1. Re:Total horseshit by Anonymous Coward · · Score: 0

      The original proof of concept was JavaScript that told you confidential information right on a website. It was pretty freaky.

  11. 15 bit/hour by manu0601 · · Score: 1

    The 15 bit/hour limit makes me skeptical. What relevant information can you hope to stand in the cache for hours?

    1. Re:15 bit/hour by virtualXTC · · Score: 1

      None. It's a proof of concept. However, (as the article mentions) just as the Rowhammer attack on RAM seemed too slow to worry about when first found, the shear number of machines affected means security researchers are going to keep picking at this, and thus it seems inevitable that netSpectre will be a huge problem in the not too distant future.

    2. Re:15 bit/hour by Anonymous Coward · · Score: 0

      Yes, this is not enough for any practical attack (that I can think of), but the attack surface is so massive that a lot of research will be done. Potentially we are soon at 1kB/hour and then it starts to become very dangerous.

    3. Re:15 bit/hour by Anonymous Coward · · Score: 1

      It doesn't have to stay in the cache, it just has to stay in memory. A server with lot's of memory likely keeps a large chunk of the file system in memory for long periods. At 16 bits/hour it would take 128 hours or about 5.3 days to get a 2048 bit key. If the key is accessed all the time, or the system is quiet, or just has a ton of memory, that's not impossible.

      In fact, it's quite likely if you have a process that connects to a system to run a command every few minutes. Perhaps some sort of monitoring software for your critical servers. Or how about your web server's private key? Isn't that accessed all the time to validate SSL Connections?

      Of course, the researches have already sped up the process by a factor of about. So that means It wold take less than 2 days to get a 2048 bit key. Seems worth it to be able to do a MIM attack for something like google.com or amazon.com, doesn't it?

    4. Re:15 bit/hour by oobayly · · Score: 2

      How do you know which 2048 bits of memory contains the key? Take a server with 64GiB of RAM, that key takes up 0.000000373% of the memory.

      Lets assume you knew which 8MiB block the key was held in, that's still 478 years at 16 bits/hour. Lets assume they can speed it up by a factor 1,000, that's 174 days. If somebody told me their safe was guaranteed to be cracked, but only if somebody worked on it 24 hours a day for 174 days I'd think "that's one fucking secure safe"

    5. Re:15 bit/hour by Anonymous Coward · · Score: 0

      You describe incremental improvement, which is how these things from from PoC to practical. The world is not static, and does not wait for you to approve improved attacks.

    6. Re: 15 bit/hour by Anonymous Coward · · Score: 0

      And that's assuming you have a gigabit internet connection and never notice that it's saturated the whole time.

  12. Neither. Basic cache operation. Until separate sec by raymorris · · Score: 2

    It would be a REALLY crappy backdoor. In this case, you're leaving looking at 15 bits per hour of random data, which will most likely be one pixel of a YouTube video or something equally interesting. Completely useless in most cases. Theoretically the bits you get might be a key, but they might also be anything else that the computer handled, and most of what computers handle isn't security keys.

    Any time you have cache, things in the cache will be faster to access than things not in the cache. That's kinda the whole point of having a cache, to speed up access to data that is used many times in a row. Caches of various are extremely important to computing, too - the can often make operations an order of magnitude faster. So nothing either sinister or stupid there - it's a simple and cheap method to make the computer run much faster.

    These general types of mechanisms will continue to exist, too. The only way you get rid of them, or many of them, is to run a completely separate, very simple (and slow) computer inside your desktop which is only used for security-sensitive operations AND have all applications use it, every time. A separate computer inside your computer, that gets ALL of your security keys? The more paranoid amongst us would have a field day with that.

  13. Re:Only not-vulnerable computers connect to Intern by Misagon · · Score: 1

    ARM cores with out-of-order execution are vulnerable to (regular) Spectre where as most ARM cores with in-order execution are not.
    ARM posted a list of which that are affected. (But they use their own nomenclature...)

    ARM Cortex-A53 and Cortex-A55 are the fastest 64-bit ARM cores without speculative execution, and yes, I think you'd want to choose 64-bit ARM (AArch64) for new applications.
    Cortex-A53 is a bit old and most easily found in the Raspberry Pi 3 Model B and 3 Model B+ single-board computers, with four cores each. Both SBCs are cheap, widely available and have a lot of support. The Model B+ runs cooler and faster (1.4 GHz) than the Model B but both need heat sinks. If a heat sink is included at all in a kit it is often too small to be able to allow the chip to run at full speed for any length of time.

    The Cortex-A55 is touted as being 20% faster than the A53 per clock. Most SoCs with the Cortex-A55 are running in a big.LITTLE configuration together with faster cores that run out-of-order.
    I have found only one SoC with only A55: the Spreadtrum SC9863, which has eight cores at up to 1.6 GHz. It was announced in May and it is so early that I can't even find a datasheet for it.
    Please do comment if you know of another option.

    --
    "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
  14. Does not know the domain by mangastudent · · Score: 4, Informative

    This latest "Net/S/M" calls them "gadgets", but they are fucking malware!

    "Gadget" is a term of art from return-oriented programming; as the good Wiki introduces this:

    [...] a computer security exploit technique that allows an attacker to execute code in the presence of security defenses such as executable space protection and code signing.

    In this technique, an attacker gains control of the call stack to hijack program control flow and then executes carefully chosen machine instruction sequences that are already present in the machine's memory, called "gadgets"....

    The "gadgets" are just convenient snippets of code that the attacker knows is already running in the target machine, like in commonly used DLLs or shared libraries.

    1. Re:Does not know the domain by GerryGilmore · · Score: 1

      But still, must not the attacker need to gain access - by actually running on the target machine - to gain control of the call stack?

    2. Re:Does not know the domain by mangastudent · · Score: 1

      Read the Wikipedia article further, the start of a ROP attack required exploiting a bug in the code of the target machine like a stack buffer overrun. Which is woefully easy, especially on Windows, which is also a primary target due to its ubiquity. The gadgets are required because execution on the stack is now generally disallowed.

    3. Re:Does not know the domain by GerryGilmore · · Score: 1

      OK, I get that, but if I know of a stack buffer overrun on a particular Windows machine, don't I still have to execute *some* code to gather anything? Also, again, how exactly does one gather anything useful from what is essentially a small slice of unknown cache data?

    4. Re:Does not know the domain by mangastudent · · Score: 1

      You use the smashed stack to execute the gadgets, their being picked as such because they're executable bits of code that can be strung together with the smashed stack into what you want. And since you can execute Turing complete programs using ROP, you can probably arrange for something interesting to be unveiled in cache timing attacks, side channels created by speculative execution that out of order CPUs use to run fast.

      You use your ROP code to arrange stuff to be in the cache, or not, and then read that memory and time the access. In the example I looked at in detail, just one bit at a time of the data of interest, see the original Google Project Zero paper, the "Variant 1: Bounds check bypass" "Theoretical explanation", it's a nice, very clear example.

    5. Re:Does not know the domain by Anonymous Coward · · Score: 1

      So basically once you've got arbitrary code execution on the remote machine, you can do what ever you want?

      No shit.

    6. Re:Does not know the domain by mangastudent · · Score: 1

      So basically once you've got arbitrary code execution on the remote machine, you can do what ever you want?

      On we have to assume all of the fastest CPUs, that do out of order processing including speculative execution. The speculative execution allows setting up side channel attacks like cache timing, and this can, depending of the details, allow you to cross many protection boundaries, between user processes, user to kernel (and not just Meltdown), different threads that were in theory sandboxed (why Chrome is now burning a bit more memory to keep sites in separate processes), even to peek into Intel Software Guard Extension enclaves.

      It's hard to exaggerate just how bad this can be; basically, run as little untrusted code on your machine as possible. I.e. as little website JavaScipt as possible, I use uMatrix with some extra severe settings in addition to uBlock Origin (ad blocker). For financial stuff, I spin up a single instance of Firefox and close it when finished. Etc. For this sort of attack though the network, at first thought, you want defense in depth, so an enemy has to get past a firewall first. Many of those are standardized by ISPs, but there's every chance the lower end ones aren't using out of order processors. Or see the Raspberry Pis, they use older super-scalar but not out of order CPUs.

    7. Re:Does not know the domain by GerryGilmore · · Score: 2

      OK, now you're falling into the paranoia level - from ANY kind of realistic standpoint!
      Please explain - without ignoring my earlier request, i.e. just howdafuck do you either know and/or be able to manipulate any cache-level data gleaned by the most inefficient process known to mankind - you can do ANYTHING by arbitrarily sniffing what is most likely stale and/or recently replaced cache memory?!?

    8. Re:Does not know the domain by mangastudent · · Score: 1

      It's not paranoia, it's been demonstrated on real systems in real time, there was even a good GUI example. These attacks extract useful data at very high rates as these things go, although this initial proof of concept network example is an exception for its slow rate of extraction ... but lots of these proofs of concepts have been sped up as they get explored. That it can be done at all is a big wakeup call.

      If you read and understand the previously mentioned original Google Project Zero paper, "Variant 1: Bounds check bypass" "Theoretical explanation", you'll understand that the cache is just a tool, used for timing side channel attacks. The data of interest is in main memory, the attacks probe protected main memory a bit or so at a time, by performing actions only allowed by speculative execution that either place other data in the cache, or don't. Then they read that data, if they get it back quickly, it was in the cache, if not, it wasn't, each read determining based on the timing whether a bit in main memory was set or not.

      Your misunderstanding seems to come from not groking that the cache is just a tool for timing side channel attacks, the memory of interest effectively stays in main memory the whole time (in truth, it's of course fetched into the cache hierarchy in the first part of the probing cycle, but that's not relevant to the attack). You must understand this concept, or take the papers on faith, or not, as you choose.

    9. Re:Does not know the domain by thegarbz · · Score: 1

      like in commonly used DLLs or shared libraries

      Loaded in random memory locations in all modern OSes.

    10. Re:Does not know the domain by mangastudent · · Score: 1

      The "gadgets" are just convenient snippets of code that the attacker knows is already running in the target machine, like in commonly used DLLs or shared libraries.

      Loaded in random memory locations in all modern OSes.

      By definition, DLLs and shared libraries must provide a way to call the code that's inside them, no matter where in memory they are located. Randomized memory layouts only increase the difficultly of some sorts of attacks, they are not a panacea.

    11. Re:Does not know the domain by thegarbz · · Score: 1

      By definition, DLLs and shared libraries must provide a way to call the code that's inside them, no matter where in memory they are located.

      All of which doesn't help at all if your side channel attack specifically is designed to leak out memory contents rather than actually sit there making system calls.

  15. HIRE A PROFESSIONAL HACKER by Anonymous Coward · · Score: 0

    Repair your credit and boost your score over 800 with Vadim Artyom. This professional Russian hacker saved me when i desperately needed a loan but couldn't get because of my poor scores. Vadim moved me from 400 to 800 within 48 hours. At first I thought it was too good to be true but right now i'm happy I just got myself a new car. I am more tha grayeful.
    If y need help, you can reach him on Email- vadimwebhack@gmail.com or Whatsapp- +380683017209
    He offers a long list of many other hacking services like phone coning, website hack, GPS tracking, removal of criminal records online, university database hack, grade change and many others, its a long list.

    1. Re:HIRE A PROFESSIONAL HACKER by Anonymous Coward · · Score: 0

      Seems legit.

  16. Just more hyper headlines by Anonymous Coward · · Score: 0

    None of this makes sense to anyone looking to gain quick access to information. You donâ(TM)t have to work that hard to gain access. Yeah sure all of these proof of concepts are great but only in a lab where time is endless. But hey it makes for great scary headlines

  17. Re:Neither. Basic cache operation. Until separate by Highdude702 · · Score: 1

    this coupled with address randomization bug would allow for known key locations, i of course did not RTFA, this is slashdot yes? but i do know if this is the first time its been done, even if only random data now. someone will figure out how to get specific data.

  18. JavaScript on a site, or even just connect tcp by raymorris · · Score: 1, Informative

    Until this attack, the attacker needed to run some code, which could be JavaScript. So infect a site, or lure a victim to your site, trumptweettoomuch.com, and you've got your code execution.

    The BASIC idea would be your JavaScript does something with the byte 01010111 10,000 times and measures how long that takes, then compares it to the same operation with byte 01011111. That allows you to know if certain other programs are using either of those bytes in their data. Run through a million iterations of trying combinations and you've retrieved the contents of another processes memory - or the kernel memory. That's the part that let's your code step out of its own process.

    Combine the ability to read the memory of other processes with a few other clever hacker techniques and you get the ability to read specific memory contents from specific locations.

    What's new in this attack is that the attacker doesn't need to run any code on the victim machine. Instead, they send 20,000 packets, half include the 01010111 byte, half include the 01011111 byte. The timing of the network driver, and therefore the timing of the responses, will vary depending on whether a different piece of system software is using the same byte. Combine that with earlier techniques and you have the ability to read the memory of programs running on the machine, without you running any code on the machine.

    These are a BIG deal for the theoretical security of the machine. The practical use is much harder, especially over the network. They achieved 15 bits per hour by saturating a direct gigabit connection. That's not very practical, unless you happen to be attacking a VM, coming from another VM on the same host hardware.

    1. Re:JavaScript on a site, or even just connect tcp by GerryGilmore · · Score: 2

      Just howdafuck is 15 bits per hour of cache data from a heavily used server going to give ANY valid data?!? I am STILL waiting for ANY reasonable explanation and - so far - have heard nothing but a bunch of paranoid "could" shit. SHOW ME!!

    2. Re:JavaScript on a site, or even just connect tcp by mangastudent · · Score: 1

      I am STILL waiting for ANY reasonable explanation and - so far - have heard nothing but a bunch of paranoid "could" shit. SHOW ME!!

      I have shown you, in the Google Project Zero paper. Did you read and understand the section of it I directed you to?

    3. Re:JavaScript on a site, or even just connect tcp by Anonymous Coward · · Score: 0

      Until this attack, Spectra and Meltdown required the user to download and execute a malicious program. This exploit claims they can do it in JavaScript (albeit very, very slowly and unlikely to produce any data of value), but I seriously doubt it. It's more FUD to scare people into installing unneeded patches and buying new hardware.

  19. Correcting myself - not random data by raymorris · · Score: 3, Interesting

    > even if only random data now. someone will figure out how to get specific data.

    They will and they did, it seems. I just read more about it.
    The basic attack would be ~random data, but people have combined it with other very clever ideas to be able to target certain memory locations.

    In those cases in which they can access memory through the kernel, such as the networking portion of the kernel, address randomization is bypassed.

    1. Re:Correcting myself - not random data by Anonymous Coward · · Score: 0

      > In those cases in which they can access memory through the kernel, such as the networking portion of the kernel, address randomization is bypassed.

      This is factually incorrect, the modern kernel in almost all consumer grade operating systems has spectre v1 gadgets hardened against this kind of attack.

    2. Re:Correcting myself - not random data by thegarbz · · Score: 1

      If on a modern system they know which memory address to target they likely already own you box.

  20. Re:Only not-vulnerable computers connect to Intern by Anonymous Coward · · Score: 0

    Which ARM processors are NOT vulnerable to Spectre and Meltdown? What is the fastest cheap computer not vulnerable?

    Maybe only computers with ARM processors should be allowed to connect to the Internet. All other computers in an organization would exchange data using a proprietary system.

    Oh boy, that's not going to backfire. Nope no sir-ee....*facepalm*

    Reasons why your idea won't work:

    1. Cost. Everytime a system was declared vulnerable, it would take time to verifiy the claim, blacklist it, patch it, and get the patches pushed out. All of which costs money. No vendor is going to do that under the current economic environment. They'd go bankrupt, even if they didn't, you'd probably be buying a new device everytime to make up the costs. Everyone else would be complaining they couldn't do anything until it was fixed, and that the inability was costing them money.

    2. Time. See also Cost, but the only real reaction to a system being declared vulnerable, is to blacklist it immediately to protect users. While demanding extensive verification to get off the blacklist. There would be immense pressure to automate this as much as possible to ensure safety, and that automation would only ensure maximum downtime for those affected.

    3. Malcontents. See also Time, but that automation could very much look like our current DMCA takedown regime. There's not much of an authority on what is considered "secure" when it comes to computers and networks. At least in the governmental sense. You'd be looking at every idiot with a grudge wanting to knock their competition offline, bare miniumum, until such an agency was up and running.

    4. Government. It wouldn't take much to mess this one up. Everything from mandatory spyware to mandatory secure boot and flat out rejection of non-bribe paying OSes / programs goes in this category.

    5. Destruction of industry start ups. See also Cost, but most start ups would not be able to afford the security testing required for internet connectivity, and would go bankrupt trying. As a result innovation pretty much dies unless it's done by the established incumbants, or the start up is loaded. The whole "2-3 guys in a garage" start up would never happen again. Not that it can currently anyway.

    6. Tracking. This blacklist is only as good as it's enforcement. There's plenty of ways to make a machine give out false attestations. Such instances would need to be litigated, tracked and monitored. The easiest way to do that is to establish some national database of all internet users that tracks the devices they connect that your LEO can search at the push of a button. If you thought anonymity was dead before, you haven't seen anything yet.

    7. False Attestations. See also tracking, but the biggest issue is how do you identify a vulnerable device? The easiest way is to have the device tell you, but that's also the easiest to hack even if you use Certificates. You can try to trick the system into giving itself up, but that can also be scanned for and the result changed. As the result is being generated by a device and network under the control of a potentially malicious actor.

    8. Criminals. There would be a market for devices that could pass the vulnerability tests and get online without giving up it's owner. There would also be a job market to research and create these devices. Criminal syndicates would probably have their own in house group for it assuming they were big enough to afford it.

    9. False safety. Given the above, you'd have a new government bureaucracy and taxes to afford it, greater emphasis on creating new vulnerabilities and exploits, an unreliable detection and prevention system, more citizen's rights threated / revoked, greater government intrusion to the lives of it's citizenry, and crap tons more of generated e-waste every year, all for no real benefit other than some idiot, and possibly corrupt, politician claiming: "You're 100% secure now!"

    No thanks. I'd rather unplug the entire dam

  21. BZZZT by Anonymous Coward · · Score: 1

    If you actually read and understand the article, the implications are tremendous. The gadgets you are so worried about are actually code that already exists in the kernel and all over application space. In fact, any well written code will be full of gadgets. Poorly written code might have fewer gadgets in it, but it will still have some.

    It's my guess that kernel's and hyper-visors are inherently full of the necessary gadgets for this attack, and it may be impossible to remove them.

    The net impact is that any group with money and good pull at any of the major ISPs will be able to use this attack to extract the private keys from any server they care to. It basically means that within a week or two, the NSA will have the private keys to any web server they wish.

    I'm currently thinking the only defense is to have your web server generate a new private key every day. Not fun.

  22. Yea, but you've got to deliver it &? by Anonymous Coward · · Score: 0

    See subject: I won't LET those who TRY via APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between characters & download).

    Yields more security/speed/reliability/anonymity vs. any SINGLE solution (99% of threats use hostnames vs. IP addresses most firewalls use) more efficiently/FASTER + NATIVELY 4 less!

    (Vs. "Bolt on 'MoAr' illogic-logic" competitors slowing you, hosts speed you up 2 ways (adblocks + hardcodes u spend most time @) vs. competition loaded w/ security bugs (DNS/AntiVir) + overheads (messagepass ('souled-out' to advertiser addons) + filtering drivers) & their complexity leads to exploitation).

    * ONLY 1 of its kind in GUI on Linux!

    Better vs. Windows model in speed/efficiency/merge.

    APK

    P.S.=> Best program of its kind bar-none & better vs. browser addons + other competitors (full of bugs, excess resource use, slowdown & complexity)... apk

    1. Re: Yea, but you've got to deliver it &? by Anonymous Coward · · Score: 0

      The hosts file is never used on incoming connections you moron.

  23. ah, in-depth research sure went into this article by ChoGGi · · Score: 1

    Academics achieved higher exfiltration speeds --of up to 60 bits/hour-- with a variation of NetSpectre that targeted data processed via a CPU's AVX2 module, specific to Intel CPUs.

    Unless they mean the attack is specific to Intel CPUs with AVX2, but it sure sounds like AVX2 is only an Intel thing?

  24. Re:ah, in-depth research sure went into this artic by ChoGGi · · Score: 1

    and replying to myself...

    an attacker can simply bombard a computer's network ports

    So, rate-limiting when you detect a bombardment? Then it'll be less than 15 bits an hour.

  25. TFS links to the white paper, doesn't it? by raymorris · · Score: 1

    If you really want the details, they are in the paper.
    https://misc0110.net/web/files...

  26. Re: Only not-vulnerable computers connect to Inter by Anonymous Coward · · Score: 0

    Check out Asus Tinker board. 2+GHz 4 Armv7 cores, 2 GB RAM. My new desktop computer!

  27. Hey stupid... apk by Anonymous Coward · · Score: 0

    See subject stupid. Hosts files stop where threats can be downloaded from. You fail & KNOW you do + hide by unidentifiable anonymous posts.

    APK

    P.S.=> But then that's ALL YOU KNOW HOW TO DO (fail)... apk

  28. Registered /.ers review of the Win64 model by Anonymous Coward · · Score: 0

    Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017

    Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid - by JazzLad April 20, 2016

    his hosts program is actually pretty good by xenotransplant August 10 2015

    his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015

    I like your host file system by Karmashock September 09 2015

    that APK guy, I use his host file by rogoshen1 Tuesday March 03, 2015

    I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017

    Linux model = faster/more efficient

    APK

    P.S.=> APK Hosts File Engine 9.0++ SR-1 32/64-bit for Windows https://www.google.com/search?...

  29. I am APK the LORD of HOSTS by Anonymous Coward · · Score: 0

    I am APK the great "LORD of HOSTS", a.k.a. AlecStaar or Alexander Peter Kowalski.

    See subject & APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / I . a m . a . f u c k i n g / a s s h o l e . r e t a r d . z i p (remove spaces between characters & download).

    I am the godlike creator of various GUI front-ends for other people's configuration files.

    Calling people ne'er-do-wells or Jealous JOWIEs is how I think I win every argument

    When people state the truth about me I get really mad and accuse them of projecting which is something I do all the time.

    Don't call me out on anything unless you are willing to prove you too can write some strings to a file programmatically

    Spamming and being a general pain in the ass is what I do

    Listen as I relive my glory days of being a college athlete in the early 80s

    You must be conspiring with the Jews and Soros if you disagree with me

    Bask in my greatness as I can do a ping as a non root user.

    Watch as I whine about my work being flagged as malware by anti-virus software.

    Witness my descent into madness

    APK

  30. APK needs to understand this by Anonymous Coward · · Score: 0

    Obligatory XKCD that you need to read and understand.