MMM
Results 1 to 12 of 12

Thread: All your chips belong to us! Security flaws puts most phones, computers at risk...

  1. #1
    Xtreme Enthusiast
    Join Date
    Oct 2004
    Location
    Wild West, USA
    Posts
    656

    Exclamation All your chips belong to us! Security flaws puts most phones, computers at risk...

    https://www.reuters.com/article/us-c...-idUSKBN1ES1BO

    Was wondering what you guys think about this. To early to tell? Some rumors online predict up to 30% drop in performance with a patch Looking forward to benchmarks comparison before and after.
    Abit IC7 P4 2.8a @4.21 | P4 3.4e @4.9 | Gainward 6800GT GS @486/1386
    Asus P4P800 SE Dothan 730-PM @ 2900 | EVGA 6800 Ultra GS @521/1376

    e8400@4.3G & 8800GTS G92 800/1932/1132 as gaming rig 24/7

    Custom self build chillbox with watercooling @-28c 24/7 | chilled wc " cpu -18c idle/-3c load
    3DMark 2005 Score Dothan & 6800U
    3DMark 2005 Score p4 & 6800GT

  2. #2
    Xtreme Mentor
    Join Date
    Apr 2003
    Location
    Ankara Turkey
    Posts
    2,657
    AMD shall use this.


    When i'm being paid i always do my job through.

  3. #3
    Xtreme Owner Charles Wirth's Avatar
    Join Date
    Jun 2002
    Location
    Las Vegas
    Posts
    12,380
    Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

    The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

    In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

    for x = 1 to 1000000; print chr$(peek(x)); next x

    This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

    How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

    As for Spectre, I am not sure of yet.
    Last edited by Charles Wirth; 01-04-2018 at 02:21 PM.
    Intel 9990XE @ 5.1Ghz
    ASUS Rampage VI Extreme Omega
    GTX 2080 ti Galax Hall of Fame
    64GB Galax Hall of Fame
    Intel Optane
    Platimax 1245W

    Intel 3175X
    Asus Dominus Extreme
    GRX 1080ti Galax Hall of Fame
    96GB Patriot Steel
    Intel Optane 900P RAID

  4. #4
    Xtreme Monster
    Join Date
    May 2006
    Location
    United Kingdom
    Posts
    2,182
    This is quite the case.

  5. #5
    Xtreme Enthusiast
    Join Date
    Aug 2008
    Posts
    889
    In other news AMD's stock is doing great.
    Intel 8700k
    16GB
    Asus z370 Prime
    1080 Ti
    x2 Samsung 850Evo 500GB
    x 1 500 Samsung 860Evo NVME


    Swiftech Apogee XL2
    Swiftech MCP35X x2
    Full Cover GPU blocks
    360 x1, 280 x1, 240 x1, 120 x1 Radiators

  6. #6
    Xtreme Addict
    Join Date
    Dec 2004
    Location
    Flying through Space, with armoire, Armoire of INVINCIBILATAAAAY!
    Posts
    1,960
    Quote Originally Posted by Charles Wirth View Post
    Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

    The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

    In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

    for x = 1 to 1000000; print chr$(peek(x)); next x

    This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

    How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

    As for Spectre, I am not sure of yet.
    (presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

    Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.
    Sigs are obnoxious.

  7. #7
    Xtreme Mentor
    Join Date
    Apr 2003
    Location
    Ankara Turkey
    Posts
    2,657
    Quote Originally Posted by iddqd View Post
    (presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

    Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.
    I believe this exploit is because of ME.


    When i'm being paid i always do my job through.

  8. #8
    Xtreme Enthusiast
    Join Date
    Oct 2004
    Location
    Wild West, USA
    Posts
    656

    Thumbs up

    Quote Originally Posted by Charles Wirth View Post
    Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

    The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

    In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

    for x = 1 to 1000000; print chr$(peek(x)); next x

    This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

    How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

    As for Spectre, I am not sure of yet.
    This was a very interesting post.

    They are keeping tabs on performance hit for now. Looks like chip companies were alerted about this back in June.
    Abit IC7 P4 2.8a @4.21 | P4 3.4e @4.9 | Gainward 6800GT GS @486/1386
    Asus P4P800 SE Dothan 730-PM @ 2900 | EVGA 6800 Ultra GS @521/1376

    e8400@4.3G & 8800GTS G92 800/1932/1132 as gaming rig 24/7

    Custom self build chillbox with watercooling @-28c 24/7 | chilled wc " cpu -18c idle/-3c load
    3DMark 2005 Score Dothan & 6800U
    3DMark 2005 Score p4 & 6800GT

  9. #9
    Xtreme Enthusiast
    Join Date
    Oct 2004
    Location
    Wild West, USA
    Posts
    656

    Thumbs up

    Quote Originally Posted by iddqd View Post
    (presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

    Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.
    Not sure about discovered it may not have been released or leaked yet. The WPA2 was secured too, until it wasn't.
    Abit IC7 P4 2.8a @4.21 | P4 3.4e @4.9 | Gainward 6800GT GS @486/1386
    Asus P4P800 SE Dothan 730-PM @ 2900 | EVGA 6800 Ultra GS @521/1376

    e8400@4.3G & 8800GTS G92 800/1932/1132 as gaming rig 24/7

    Custom self build chillbox with watercooling @-28c 24/7 | chilled wc " cpu -18c idle/-3c load
    3DMark 2005 Score Dothan & 6800U
    3DMark 2005 Score p4 & 6800GT

  10. #10
    Xtreme Owner Charles Wirth's Avatar
    Join Date
    Jun 2002
    Location
    Las Vegas
    Posts
    12,380
    It was an example of reading memory, not arming a targeted payload. I just started peeking at memory very early.

    The problem is data centers and VM space having someone dumping protected memory to a file, the advantage of doing this to a data center is taking a snapshot of all the VM's.

    It comes down to shared kernel mapping and it appears someone found where it may be unprotected or the chipset issues the command looking directly before it is encrypted.

    Unlike my example, this Meltdown code would have to be targeted for its victim OS and hardware config based on various reports.
    Intel 9990XE @ 5.1Ghz
    ASUS Rampage VI Extreme Omega
    GTX 2080 ti Galax Hall of Fame
    64GB Galax Hall of Fame
    Intel Optane
    Platimax 1245W

    Intel 3175X
    Asus Dominus Extreme
    GRX 1080ti Galax Hall of Fame
    96GB Patriot Steel
    Intel Optane 900P RAID

  11. #11
    Xtreme Enthusiast
    Join Date
    Feb 2010
    Posts
    578
    AMD has claimed publicly that their chips are immune to Meltdown but vulnerable to at least one form of the Spectre attack (the other poses 'near zero risk').

    Patching against Spectre allegedly comes with no real performance hit.

    Patching against Meltdown is a different matter entirely.

    Until we see the combined force of OS kernel patches AND microcode updates, we won't know the full performance impact of the changes necessary to mitigate both flaws. Google claims they have their own way to patch against the vulnerability that they've used internally for quite awhile which may work out better than fixes like KTPI. Though honestly I don't know if their technique ('Retpoline') and KTPI are mutually exclusive.
    Last edited by drmrlordx; 01-05-2018 at 02:50 PM.

  12. #12
    Xtreme Addict
    Join Date
    Dec 2004
    Location
    Flying through Space, with armoire, Armoire of INVINCIBILATAAAAY!
    Posts
    1,960
    Quote Originally Posted by Charles Wirth View Post
    It was an example of reading memory, not arming a targeted payload. I just started peeking at memory very early.

    The problem is data centers and VM space having someone dumping protected memory to a file, the advantage of doing this to a data center is taking a snapshot of all the VM's.
    I see - I misunderstood your post. I guess you could look at what all the other VMs are doing on the machine, I hadn't thought of that. All the cloud service providers are going to freak out over this, of course, but snooping on what people's VMs are doing will likely yield absolutely nothing of interest.
    Sigs are obnoxious.

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •