Announcement

Collapse
No announcement yet.

New vulnerability in Intel CPUs since Pentium 4

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Click image for larger version

Name:	mdintelbug.jpg
Views:	1
Size:	56.8 KB
ID:	768594

    Comment


    • #22
      If its only a server related issue, its much less of a problem as you can just up the level of server grunt to replace the percentage loss from any patches that may be developed. As it cannot get into a user PC unless there is some security flaw, it sounds like just another exploit and as there have been many nasty ones over time, it may not be any worse than any other of the nasty ones. If the security on a user computer is lax and an exploit like this can get onto the machine, a boot disk image will wipe it out in any case.

      From the way its being hyped, it sounds like the nonsense that occurred before the year 2000 where the world was supposed to end but at midnight nothing happened. Some old mainframes had their software updated so it could handle full years (2000 versus 00) but the rest was nonsense. This is sounding much the same. Now being a cynic at best, there is another security concern, a single instance of an exploit being used as an excuse for security agencies to install snooping software on servers around the world through the patches that may be applied to so many servers is probably a much greater risk than what the exploit is being described as.
      hutch at movsd dot com
      The MASM Forum

      www.masm32.com

      Comment


      • #23
        Originally posted by Steve Hutchesson View Post
        From the way its being hyped, it sounds like the nonsense that occurred before the year 2000 where the world was supposed to end but at midnight nothing happened. Some old mainframes had their software updated so it could handle full years (2000 versus 00) but the rest was nonsense.
        I do not think the "rest was nonsense". I know that in the company I worked for at that time, we worked our asses of in overtime to hunt down all possible occurrences of the Y2K-bug in our software, fixing it/testing it/deploying it to the clients. And yes - we were lucky to find all problematic pieces of code. Our software run smoothly after 1999-12-31. But not because it was "nonsense" aka Y2K wasn't an issue for us. But because we invested lots of work in it.

        And judging from what others reported, thy did the same thorough code analysis and fix(es). And to me that's the reason because most people outside the industry think it was overhyped: most software got fixed and deployed in time, thanks us all. And therefore no major incidents happened. And not because it was a non-issue.

        I unfortunately do not know enough about CPUs, so I can't really judge the seriousness of this one. For example this thread is interesting to me, because it analyzes the impact on VMs. But I don't "get the beef".

        But I trust a few people from whom I've read comments about the issue at hand, because of their reliable and decent track records.

        Comment


        • #24
          Knuth,

          You are living proof that the world did not end at midnight 1999. Now lets face it, if every computer on the planet went BANG, the sun would rise the next day, the moon would continue to orbit the planet, it would be cold in winter, hot in summer and abacus sales would hit the roof.
          hutch at movsd dot com
          The MASM Forum

          www.masm32.com

          Comment


          • #25
            Javascript is all that is needed to read all memory.
            Couldn't edit this post with JavaScript off.


            According to the blog post below, a banner on a web page with javascript could read all your passwords.
            And to top it off, the link below won't completely display because it uses Javascript!
            So, read at your own risk! https://blog.oo-software.com/en/melt...eid=bbffe27fcf


            I'm trying running without JavaScript and things aren't going well (barely got this to post.)

            Blocking individual sites using Chrome does NOT appear to work.
            I added several sites to the blocked list and they still work.
            Completely turning off Javascript does work.

            According to the blog above we need to contact BIOS manufacturer for an update.
            He also says this effects Android and Apple cell phones.

            If the blog above is correct, this is a nightmare for many.

            Tried downloading Chrome with Javascript off and couldn't do it.
            https://www.google.com/chrome/browse...top/index.html

            With JavaScript on it downloads the current version for 32-bit:
            Version 63.0.3239.132 (Official Build)

            https://www.tesla.com/roadster

            Comment


            • #26
              Thanks Mike for the info,

              To clear off your passwords or logins id that are stored on the web browser cache, I use CCLeaner
              It does look like we need to run this CCLeaner immediately after each usage of the browser !

              Perhaps a firewall appliance can stop hackers from intrusion into our network?

              Comment


              • #27
                Originally posted by Mike Doty View Post
                Javascript is all that is needed to read all memory.
                Couldn't edit this post with JavaScript off.

                According to the blog post below, a banner on a web page with javascript could read all your passwords.
                According to a marketing post on a commercial site by someone who "has a very broad sales and account management background, having previously been employed by various international companies in both senior sales and customer service roles." Yep obviously an expert in such issues. And guess what - their disk imaging software just happens to be a solution.

                Classic FUD.


                --
                [URL="http://www.camcopng.com"]CAMCo - Applications Development & ICT Consultancy[/URL][URL="http://www.hostingpng.com"]
                PNG Domain Hosting[/URL]

                Comment


                • #28
                  Intel AMT Security Issue Lets Attackers Bypass Login Credentials in Corporate Laptops
                  "The trouble with quotes on the Internet is that you can never know if they are genuine." - Abraham Lincoln.

                  Comment


                  • #29
                    Another Hack on Intel ! But this need physical access which is tougher to do

                    Comment


                    • #31
                      Another Hack on Intel !
                      So what would you expect?

                      The noted robber Willie Sutton was once asked , "Willie, why do you rob banks?" Mr. Sutton replied, "Because that's where they keep the money."

                      If you want to cause havoc and/or steal passwords and/or purloin personal info, it makes a lot of sense to hack Intel rather than to hack AMD or any other chip... because that's where they keep the users!

                      MCM

                      Comment


                      • #32
                        We had an 'interesting' experience with the January Meltdown patch for Win7 (KB4056894). Has anyone else experienced anything like this?

                        Every other IO-heavy process in the system showed the expected 12%-20% slowdown, but this particular process experienced a 350%+ slowdown. We ruled out everything else on the machine before eventually backing off the patch (on the backup version of this machine, identical config). Immediately performance returned to the pre-patch level.

                        The process builds data from sequential files into a data store of headers and details. Our client receives interface files from many sources, some tiny (5 records) and some huge (200k records). Most are small, 100-200 records. These sit in a directory until ready to process. There were about 226,000 files to process. Friday, this process ran in 7 minutes. The Meltdown patch was applied on Saturday, and Monday's run times were between 25 and 30 minutes!

                        We hacked up a few test versions of the code and narrowed it down to the open/close of these sequential files. Has anyone else seen this kind of a performance penalty from sequential open/close after the Meltdown patch?

                        For background, the machines are high-end Dell 7010, newer 10-core Xeon processors, 64GB ram, all SSD drives.We replicated similar results using an HP server with similar specs, and a beefy workstation with slightly lower specs -- in all cases the pre-/post- patch slowdown percentage remained similar (+/- 10%)..

                        Comment


                        • #33
                          Try running that process on a non-SSD machine.

                          Amongst the various articles that I've read about the Meltdown issue was one that mentioned that non- SSD systems might experience much less of a perfomance hit than SSD systems. See e.g. https://linustechtips.com/main/topic...d-performance/

                          My SSD performance measured with CrystalDiskMark is nearly half what it used to be in Seq. Writes and 4k Writes. I don't notice any difference in speed, but if it really is that much slower, I'm disappointed.
                          It doesn't actually explain that huge difference you're experiencing, though.

                          Comment


                          • #34
                            Originally posted by Knuth Konrad View Post
                            Try running that process on a non-SSD machine.
                            Thanks Knuth. I've done a lot of reading in the last 48 hours, and I had not seen that. The last application server in this pool that had HDs was decommissioned in November/December. I'll have to see if I can revive it and run some tests. Thanks very much for the lead!

                            Comment


                            • #35
                              Just did the ordinary benchmarks on my PCI express Intel SSD and its running at about half speed. Win10 64 bit professional which is auto patched daily by auto update. ramdisk still runs at about 7.5 gig/sec.
                              hutch at movsd dot com
                              The MASM Forum

                              www.masm32.com

                              Comment


                              • #36
                                Originally posted by Knuth Konrad View Post
                                Try running that process on a non-SSD machine.
                                While we try to retrieve the prior application server (below), I decided to do the best test I could to prove the theory. We used the SSD workstation (from above) and installed a single 10k rpm drive just to get a "spinning rust" test.

                                The pre-/post- patch difference is significantly less than 350%, slightly below the 12%-20% we had expected, proving the theory that traditional drives suffered less. Unfortunately, the HD run time was roughly 45% more than even the patch-crippled SSD. In effect, the percentage was better but the overall run time was worse

                                After pondering the results, I suspect -- but don't yet have a way to prove -- that the slowness of the traditional HD is masking the overhead of the patch.

                                I'll still attempt (as time permits), to do a test on the higher-end app server. It had a raid-60 array spread across two channels and had an top transfer rate of 800+ MB/s (higher than the SSD I tested). This might give a little insight if this is a SATA vs SAS, driver, Rust vs SSD, issue. If I find anything useful, I'll try to remember to post the results.

                                Comment


                                • #37
                                  Just to point out that AMD revised their guidance about Spectre v2. They're no longer claiming that their processors are not vulnerable, just that it's "very difficult to exploit" and they're releasing microcode patches to mitigate the vulnerability.

                                  Microsoft is also exploring the interesting approach of building some limited mitigation against Spectre v1 into their compilers, using the lfence instruction to block speculative execution at points where the compiler thinks there could be vulnerability (e.g.: code that uses a variable index to access elements in an array).
                                  Mike Stefanik
                                  sockettools.com

                                  Comment


                                  • #38
                                    Gibson research has released a utility to determine a system's level of vulnerability. From their web site:
                                    Easily examine and understand any Windows
                                    system's hardware and software capability to
                                    prevent Meltdown and Spectre attacks.
                                    Real programmers use a magnetized needle and a steady hand

                                    Comment


                                    • #39
                                      Beware using Steve Gibson's utility to turn off the Meltdown patch for testing, it did not work here. It said it was disabled but had no effect in performance after the required reboot (see my earlier post) . Only uninstalling the patch worked.

                                      Standard disclaimers: there is potential risk turning this patch off if the machine is running untrusted code, used to surf the net and a bunch more.

                                      Comment


                                      • #40
                                        Originally posted by Raymond Leech View Post
                                        After pondering the results, I suspect -- but don't yet have a way to prove -- that the slowness of the traditional HD is masking the overhead of the patch.
                                        That might very well be the case.

                                        We're you able to pinpoint which I/O operation caused the drastic performance loss? From what you mentioned about the appliation, I conclude that it
                                        a) reads huge amounts of individual (sequential aka "text"?) files
                                        b) writes it back to some (to us) unknown datastore

                                        Does the loss happen at the reading side or the writing side of things?

                                        Also - and a bit unrelated, you mentioned the large number of files (226k) being pocessed. Does the same performace loss happen when dealing with (a lot) less files? Maybe that application isn't the real culprit here, but the combination of the patch and how it dealt with I/O in combination with a huge number of files (presumably) located in a single folder.

                                        I know ... all speculation, but even if completely off, hopfelly food for though for you.

                                        Comment

                                        Working...
                                        X