Discussion in 'other security issues & news' started by Minimalist, Jan 2, 2018.
What a big darn headache with all this I have two laptops I'm not even updating I'm just going to take my chances and rely on the AV installed they don't see a whole lot of internet use anyway.
Several scanners at VT are giving a warning about it. I guess those are FP's, but let's wait.
InSpectre.exe - Version 0.0.6590.1
SHA-256 - F263A23494D22A05F707FAF4D0F4CC147B276F255309007D5F27D000A54B5372
Clearly a yes answer here. For the first time I've tried no script and am sticking with it
Yes, installed now. Whitelisted Wilders .
What key thing is this?
At the risk of stating the obvious to the good denizens of this place, that security should extend to blocking ads too, not only script blocking. Given that few people fully block scripts and are trusting of some sites, it's important to restrict their exposure to bad-ads.
As well, minimising the appearance of credentials in any given browser session is a good idea, as part of your operational practice. That is to say, keep your banking well away from shopping at online stores. If you are inputting financially sensitive information, I'd do so in a freshly booted session, or as I actually do, on a live persistent USB stick dedicated solely to the relevant institutions, never used for general browsing.
HitmanPro flags it as a trojan:
Location D:\Users\Robert\Desktop\Shared Space
Size 122 KB
Time 0.0 days ago (2018-01-16 09:14:43)
Product "InSpectre", by Steve Gibson
Publisher Gibson Research Corp.
Description InSpectre: Meltdown and Spectre?
Copyright Copyright © 2018 Gibson Research Corp.
RSA Key Size 2048
Here are the vendors that raise a red flag on it via VirusTotal:
Antivirus Result Update
Cylance Unsafe 20180116
Cyren W32/GenBl.1A6274CD!Olympus 20180116
Endgame malicious (moderate confidence) 20171130
Fortinet W32/Generic.A!tr 20180116
Kaspersky HEUR:Trojan.Win32.Generic 20180116
McAfee Artemis!1A6274CDD02B 20180116
McAfee-GW-Edition Artemis 20180116
Sophos AV Mal/Dorf-A 20180116
TrendMicro TROJ_GEN.F0C2C00AG18 20180116
TrendMicro-HouseCall TROJ_GEN.F0C2C00AG18 20180116
ZoneAlarm by Check Point HEUR:Trojan.Win32.Generic 20180116
All or most at least are detecting using a generic sig.. These are used by their heuristic/etc. scanners to detect suspicious activity from unknown/low rep. processes. Given it appears the GRC software is able to modify reg. settings and the like related to the Meltdown and Spectre OS patches, I can see why these AV solutions are alerting. Personally, I believe GRC needs to remove any code from the tool that can do like activities.
-EDIT- This also brings up the point that it might also be advised to monitor modification activity to the parent registry key where the FeatureSettingsOverride key value is stored since malware can also perform like activity.
Do you think the tool is reliable?
For me it's too fast in the analysis.
In my old PC with XP is instantaneous.
The other tools do not work, this yes.
I have not installed Powershell and any version of the NET Framework...............
Not as strict as that, but I try. uBO medium mode for bad-ads; separate browser instance for financial transactions, profile with private browsing mode, and only password manager and NoScript add-ons. Apologies if straying OT.
After the Ashampoo® Spectre Meltdown CPU Checker incident, I would stay away from all software like this.
Yes, exactly. This is essentially a GUI version of what we were doing so this makes it a lot easier instead of manually editing registry. You must run it as Admin to make those changes though.
Yes, default would probably best in the case where a user does not have a BIOS/microcode update yet. That way Windows will deal with things accordingly.
I would only suggest this workaround that we were discussing only in the situation where users are having those WHEA hardware (CPU related) errors in Event Viewer and system instability due to the microcode update. Or I suppose in cases of gamers who are experiencing dramatic system slowdowns. But I believe only Broadwell and Haswell are most affected by performance. I'm hoping when Intel releases new microcode without the flaws, it should perform much better since the initial microcode was CPU causing page faults.
uMatrix is also a good extension for controlling scripts. From the same dev as uBlock Origin. Runs on both Chrome and Firefox. uBlock Origin also allows some script control in advanced mode, but not as fine grained as uMatrix.
I made the switch from NoScript to this a while back. I just found it easier to control what breaks in a website when you start blocking scripts by domain. Plus I like using the same extension on both browsers, easier to keep my ducks in a row!
I don't think separate browser instance works fully, because the Spectre-class attacks can read cross-process and also into kernel memory. As long as the bad-scripts are running while you also do the separate browser, they could potentially read whatever's in its process address space. Naturally, if you can rely on NoScript or uMatrix or uBO to stop nasty scripts then that's less risky, but who knows what actually gets to run, you "have to " run some to get functionality!
The thing one can use though, is that these attacks are read-only (and would have to exfiltrate data via the internet), and would not survive a reboot.
Personally, I've never kept important passwords in browser or password managers (Lastpass), in the browser. At least KeePass say that they encrypt passwords in memory (though the encryption key is there somewhere, presumably unless you used 2FA, which I do). It's also possible to add "decorations" to supplement stored passwords, so what actually goes into the password field is not completely what's in the database.
Also, obviously, we're at a very early stage of knowing what threats are realistically possible, and I think when the researchers said they were hard to write, that's true - the PoC were using known targets, so memory scraping is much easier. My guess is that initial browser exploits will be written for specific browser implementations, and vulnerable password managers.
This also makes browser mitigations very important, so adjustments to the Jit will be very welcome, including brutal but probably fairly effective things like timer fuzzing which FF at least are doing.
Regarding OT, I wonder what readers think in terms of when and how to split this discussion? It may be rather early, because the mitigation and threat scene is very unclear (at least to me), and the practical steps that might help to reduce our exposure are things we're having to feel our way with, as here. However, I do think it's useful to be discussing how-to-handle-it-practically, it's all we can do given the absence or unavailability of CPU/OS/hypervisor mitigations, or clearly articulated and well-informed threat models.
It's also easy to lose context of this in relation to "run-of-the-mill" exploits which may often be more damaging and are really out there!
Any comments on this:
It should not perform suspicious actions.
It does not require Administrator rights to work.
I have also enabled in OSA in the "Advanced" section all the rules (no the last one) without receiving warnings.
So the best would be to use the approach by Microsoft (via PowerShell)
I've seen some suggestions of running umatrix for the scripts and noscript with scripts all whitelisted for the xss. Haven't tested it though.
Hi, and thanks. I didn't know there would be updates to motherboards as well as operating systems. I searched the Asus website for my motherboard and it looks like there is a BIOS update 2018/01/12 that includes "Updated Intel CPU microcode", so I guess this is also for the Meltdown thing.
What is the difference between the microcode in the BIOS and the microcode installed e.g. with Linux?
Hi, I have enabled Chrome's Strict Site Isolation. That website seems to suggest it is enough? Or should I still use some extension to block js by default?
I don't recall if this had been mentioned yet, but for users who have motherboard manufacturers who wont release a BIOS/microcode update, have a longer delay until release, or simply will never receive a BIOS/microcode update, VMware has a solution.
VMware CPU Microcode Update Driver
Please keep in mind that this kernel-mode driver must apply the microcode at each system boot time and therefore you need to keep this driver installed at least until you receive a proper BIOS/microcode update. Also, please keep in mind that the latest Intel microcode is known to be buggy on certain systems. So I would strongly suggest to wait until Intel releases a more stable microcode update, regardless.
Now, this kernel-mode driver essentially just updates the microcode upon each boot.
This driver is SHA1/SHA256 signed by VMware but it is NOT cross-signed by Microsoft Windows. Therefore, you would have to keep SecureBoot disabled to utilize this driver.
However, it is one option for those who will never receive a BIOS/microcode.
I think I'll try this option cause I won't receive microcode update. Thanks.
I saw a report earlier that this driver didn't execute early enough to have the requisite effect, but I'm not sure about this.
Personally I'm waiting to see what happens with official Windows support for microcode update. It's technically quite possible for it to happen, and I even agree with it not happening at this point, because I'd much rather get something effective and tested. MS don't really want the flak, but practically, that is the solution that will be needed. Really, we need some official tools to allow granularity and testing, maybe that's what they're working on, who knows. So you can revert and suchlike.
If I do not get the Bios update, and MS won't act, then I'll be swapping Windows out for Linux as the host and running the Windows in a VM on affected machines, since Linux does have the microcode patches. I'm not sure how long I'll be willing to wait.
Anyway, for brave souls, let us know!
Of note about the GRC web site, https://www.grc.com/inspectre.htm, Microsoft is blacklisting it in SmartScreen. And I believe "other changes" are on their way.
There are some posts about this. I have tried it and others have tried it but the microcode isn't patched in early enough in the boot sequence for the kernel to recognize its there and apply the appropriate mitigations. It does no harm to try and maybe someone will be able to get it working and let us know how.