STE WILLIAMS

Sysadmins have been advised to watch for a coming HP printer firmware update that will plug a remote code execution vulnerability (among others) in its MFP-586 and the M553 printers.

News of the threat emerged from a Foxglove Security deep-dive into printer security that saw the researchers warn HP of problems in August. The post, by Foxglove’s Steeve Breen, said “HP notified us that a fix has been developed and is being released this week.”

The researchers also discovered other bugs, but led with the remote code execution (RCE) that they found after considerable efforts to extract usually-encrypted system files, plus reverse-engineering HP’s firmware signature validation. After those chores the researchers concluded: “it may be possible to manipulate the numbers read into int32_2 and int32_3 in such a way that the portion of the DLL file having its signature verified could be separated from the actual executable code that would run on the printer.”

Having worked out how to construct non-HP software solution packages, the researchers were ready create malware from the main class of HP’s ThinPrint client.

The actions performed by their proof of concept are:

• 1) Download a file from http://nationalinsuranceprograms.com/blar;
• 2) Execute the command specified in the file on the printer;
• 3) Wait for 5 seconds; and
• 4) Repeat.

Foxglove posted its malicious code on GitHub.

On the way to discovering the RCE vulnerability, the researchers also found ways to retrieve even PIN-protected print jobs, using path traversal, plus a PostScript manipulation bug and two unsecured factory reset conditions.

The reset vulnerability means an attacker could put both the printer’s administrative password (empty) and its SNMP community string (public).

Readers may particularly appreciate one of the details of Foxglove’s work: getting at encrypted code.

HP’s printers use FIPS-compliant encryption on their internal storage and the hackers weren’t about to try to get around that. Instead, they substituted the HP drive for a Toshiba unit that doesn’t support encryption.

When the printer was powered on, they were able to install both operating system and firmware from USB onto an unencrypted drive, yielding access to much of the drive’s content on “a standard PC”.

To get to the Windows CE directory, they used the

nkbintools

extractor.

That didn’t, however, let them into the /Core partition. For that, the researchers needed to grab a copy with the dd utility, and put in the hard work looking at DLL files to extract the software they were looking for. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/21/patch_coming_for_hp_printer_vulnerabilities/

Texas Rangers have obtained a search warrant for the contents of a blood-splattered iPhone SE belonging to gunman Devin Kelley who killed 26 people in a murder-suicide at a church.

Over the weekend, the US state’s cops served the Cupertino phone-flinger a warrant demanding photos, messages and other potential evidence on Kelley’s iPhone as well as those stored on its associated iCloud account. Investigators also have a warrant to extract data stored on Kelley’s second handset, an LG flip-phone. He was named as the shooter in the November 5 Sutherland Springs mass-murder.

Specifically, the cops want all the messages, calls, social media passwords, contacts, photos, videos and other data since January 1, 2016, from the bloodied iPhone and iCloud account.

At this point it is not known if the files sought can all be pulled from backups held in the iCloud account, or if some will need to be obtained directly from the iPhone. Using iCloud for backups is optional.

The iPhone SE has a fingerprint sensor – so the dead man’s fingertips could be used to log into the device – however, it is now too late to use prints: a passcode must be entered after several hours have passed without a login.

Since the iPhone cannot be unlocked, and its file system is likely encrypted, Apple will be needed to find a way to extract and decrypt the data within, just like it was ordered to do in the San Bernardino murder case in California. In that investigation, Apple refused to comply with the government’s demands that it assist g-men in physically accessing the contents of a killer’s iPhone 5C.

The distinction between what is in the cloud and what is kept locally on the phone is important to make, as Apple maintains a policy of handing over data stored on its cloud service to agents and cops who show up armed with a warrant, while getting info from a locked and encrypted device itself is a far more complex and contentious issue.

Evidence … Kelley’s bloodied iPhone SE after the killer blew his brains out (Source: Court records)

Should investigators be unable to get the files from the iCloud backups, Apple could once again find itself battling a court order to hack into the handset to give officials access.

Last year, such an order was issued for an iPhone owned by one of San Bernardino shooters, prompting Apple to refuse the order on the grounds it would spark days of bad publicity, er, sorry, jeopardize the security of all its handsets and set a terrible precedent. The FBI eventually found a secret means to forcibly unlock the phone.

Now, with another iPhone at the heart of a mass-shooting tragedy, it is widely expected authorities will once again demand that Apple, somehow, open up a secured iThing.

In this case, the battle could be the catalyst to give law enforcement agencies backdoor access to break encryption in any device on demand – something privacy and security advocates alike have strongly opposed.

Apple declined to comment. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/20/warrant_texas_shooter_iphone/

Texas Rangers have obtained a search warrant for the contents of a blood-splattered iPhone SE belonging to gunman Devin Kelley who killed 26 people in a murder-suicide at a church.

Over the weekend, the US state’s cops served the Cupertino phone-flinger a warrant demanding photos, messages and other potential evidence on Kelley’s iPhone as well as those stored on its associated iCloud account. Investigators also have a warrant to extract data stored on Kelley’s second handset, an LG flip-phone. He was named as the shooter in the November 5 Sutherland Springs mass-murder.

Specifically, the cops want all the messages, calls, social media passwords, contacts, photos, videos and other data since January 1, 2016, from the bloodied iPhone and iCloud account.

At this point it is not known if the files sought can all be pulled from backups held in the iCloud account, or if some will need to be obtained directly from the iPhone. Using iCloud for backups is optional.

The iPhone SE has a fingerprint sensor – so the dead man’s fingertips could be used to log into the device – however, it is now too late to use prints: a passcode must be entered after several hours have passed without a login.

Since the iPhone cannot be unlocked, and its file system is likely encrypted, Apple will be needed to find a way to extract and decrypt the data within, just like it was ordered to do in the San Bernardino murder case in California. In that investigation, Apple refused to comply with the government’s demands that it assist g-men in physically accessing the contents of a killer’s iPhone 5C.

The distinction between what is in the cloud and what is kept locally on the phone is important to make, as Apple maintains a policy of handing over data stored on its cloud service to agents and cops who show up armed with a warrant, while getting info from a locked and encrypted device itself is a far more complex and contentious issue.

Evidence … Kelley’s bloodied iPhone SE after the killer blew his brains out (Source: Court records)

Should investigators be unable to get the files from the iCloud backups, Apple could once again find itself battling a court order to hack into the handset to give officials access.

Last year, such an order was issued for an iPhone owned by one of San Bernardino shooters, prompting Apple to refuse the order on the grounds it would spark days of bad publicity, er, sorry, jeopardize the security of all its handsets and set a terrible precedent. The FBI eventually found a secret means to forcibly unlock the phone.

Now, with another iPhone at the heart of a mass-shooting tragedy, it is widely expected authorities will once again demand that Apple, somehow, open up a secured iThing.

In this case, the battle could be the catalyst to give law enforcement agencies backdoor access to break encryption in any device on demand – something privacy and security advocates alike have strongly opposed.

Apple declined to comment. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/20/warrant_texas_shooter_iphone/

Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts.

The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, to run code beneath the operating system to spy on or meddle with the computer completely out of sight of other users and admins. The holes can also be exploited by network administrators, or people masquerading as admins, to remotely infect machines with spyware and invisible rootkits, potentially.

Meanwhile, logged-in users, or malicious or commandeered applications, can leverage the security weaknesses to extract confidential and protected information from the computer’s memory, potentially giving miscreants sensitive data – such as passwords or cryptographic keys – to kick off other attacks. This is especially bad news on servers and other shared machines.

In short, a huge amount of Intel silicon is secretly running code that is buggy and exploitable by attackers and malware to fully and silently compromise computers. The processor chipsets affected by the flaws are as follows:

• 6th, 7th and 8th Generation Intel Core processors
• Intel Xeon E3-1200 v5 and v6 processors
• Intel Xeon Scalable processors
• Intel Xeon W processors
• Intel Atom C3000 processors
• Apollo Lake Intel Atom E3900 series
• Apollo Lake Intel Pentiums
• Celeron N and J series processors

Intel’s Management Engine, at the heart of today’s disclosures, is a computer within your computer. It is Chipzilla’s much maligned coprocessor at the center of its vPro suite of features, and it is present in various chip families. It has been assailed as a “backdoor” – a term Intel emphatically rejects – and it is a mechanism targeted by researchers at UK-based Positive Technologies, who are set to reveal in detail new ways to exploit the ME next month.

The Management Engine is a barely documented black box. it has its own CPU and its own operating system – recently, an x86 Quark core and MINIX – that has complete control over the machine, and it functions below and out of sight of the installed operating system and any hypervisors or antivirus tools present.

It is designed to allow network administrators to remotely or locally log into a server or workstation, and fix up any errors, reinstall the OS, take over the desktop, and so on, which is handy if the box is so messed up it can’t even boot properly.

The ME runs closed-source remote-administration software to do this, and this code contains bugs – like all programs – except these bugs allow hackers to wield incredible power over a machine. The ME can be potentially abused by to install rootkits and other forms of spyware that silently snoop on users, steal information, or tamper with files.

SPS is based on ME, and allows you to remotely configure Intel-powered servers over the network. TXE is Intel’s hardware authenticity technology. Previously, the AMT suite of tools, again running on ME, could be bypassed with an empty credential string.

Today, Intel has gone public with more issues in its firmware. It revealed it “has identified several security vulnerabilities that could potentially place impacted platforms at risk” following an audit of its internal source code:

In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of our Intel Management Engine (ME), Intel Server Platform Services (SPS), and Intel Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience.

The flaws, according to Intel, could allow an attacker to impersonate the ME, SPS or TXE mechanisms, thereby invalidating local security features; “load and execute arbitrary code outside the visibility of the user and operating system”; and crash affected systems. The severity of the vulnerabilities is mitigated by the fact that most of them require local access, either as an administrator or less privileged user; the rest require you to access the management features as an authenticated sysadmin.

Intel ME controller chip has secret kill switch

READ MORE

But as Google security researcher Matthew Garrett pointed out in the past hour or so, the aforementioned AMT flaw, if not patched, could allow remote exploitation.

In other words, if a server or other system with the AMT hole hasn’t been updated to kill off that vulnerabilities, these newly disclosed holes will allow anyone on the network to potentially log in and execute malicious code within the powerful ME coprocessor.

“The ME compromise presumably gives you everything the AMT compromise gives you, plus more,” said Garrett via Twitter. “If you compromise the ME kernel, you compromise everything on the ME. That includes AMT, but it also includes PTT.”

He explained, “PTT is Intel’s ‘Run a TPM in software on the ME’ feature. If you’re using PTT and someone compromises your ME, the TPM is no longer trustworthy. That probably means your Bitlocker keys are compromised, but it also means all your remote attestation credentials are toast.”

Garrett said if an exploit allows unsigned data to be installed and interpreted by the ME, an attacker could effectively trigger the reinfection of malware after every ME reboot. Were that to happen, the only way to fix things would be to reflash the hardware by hand. At that point, he said, it would probably be cheaper just to get new hardware.

Thanks, Intel. pic.twitter.com/w16IyKuCtu

— The Register (@TheRegister) November 20, 2017

Intel said systems using ME Firmware versions 11.0, 11.5, 11.6, 11.7, 11.10, and 11.20, SPS Firmware version 4.0, and TXE version 3.0 are affected. The cited CVE-assigned bugs are as follows:

• Intel Manageability Engine Firmware 11.0.x.x/11.5.x.x/11.6.x.x/11.7.x.x/11.10.x.x/11.20.x.x
  • CVE-2017-5705: “Multiple buffer overflows in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5708: “Multiple privilege escalations in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
  • CVE-2017-5711: “Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege.” Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
  • CVE-2017-5712: “Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege.” People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
• Intel Manageability Engine Firmware 8.x/9.x/10.x
  • CVE-2017-5711: “Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege.” Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
  • CVE-2017-5712: “Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege.” People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
• Server Platform Service 4.0.x.x
  • CVE-2017-5706: “Multiple buffer overflows in kernel in Intel Server Platform Services Firmware 4.0 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5709: “Multiple privilege escalations in kernel in Intel Server Platform Services Firmware 4.0 allows unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
• Intel Trusted Execution Engine 3.0.x.x
  • CVE-2017-5707: “Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware 3.0 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5710: “Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware 3.0 allows unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.

Chipzilla thanked Mark Ermolov and Maxim Goryachy at Positive for discovering and bringing to its attention the flaw CVE-2017-5705, which sparked the aforementioned review of its source code for vulnerabilities.

Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs. If you are at risk, you must obtain and install firmware updates from your computer’s manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine.

Lenovo was quick off the mark with patches for its gear ready to download.

We’ll give you a roundup of fixes as soon as we can. It’s not thought Apple x86 machines are affected as they do not ship with Intel’s ME, as far as we can tell.

Today’s news will no doubt fuel demands for Intel to ship components free of its Management Engine – or provide a way to fully disable it – so people can use their PCs without worrying about security bugs on mysterious secluded coprocessors. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/20/intel_flags_firmware_flaws/

Intel today admitted its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE) are vulnerable to multiple worrying security flaws, based on the findings of external security experts.

The firmware-level bugs allow logged-in administrators, and malicious or hijacked high-privilege processes, to run code beneath the operating system to spy on or meddle with the computer completely out of sight of other users and admins. The holes can also be exploited by network administrators, or people masquerading as admins, to remotely infect machines with spyware and invisible rootkits, potentially.

Meanwhile, logged-in users, or malicious or commandeered applications, can leverage the security weaknesses to extract confidential and protected information from the computer’s memory, potentially giving miscreants sensitive data – such as passwords or cryptographic keys – to kick off other attacks. This is especially bad news on servers and other shared machines.

In short, a huge amount of Intel silicon is secretly running code that is buggy and exploitable by attackers and malware to fully and silently compromise computers. The processor chipsets affected by the flaws are as follows:

• 6th, 7th and 8th Generation Intel Core processors
• Intel Xeon E3-1200 v5 and v6 processors
• Intel Xeon Scalable processors
• Intel Xeon W processors
• Intel Atom C3000 processors
• Apollo Lake Intel Atom E3900 series
• Apollo Lake Intel Pentiums
• Celeron N and J series processors

Intel’s Management Engine, at the heart of today’s disclosures, is a computer within your computer. It is Chipzilla’s much maligned coprocessor at the center of its vPro suite of features, and it is present in various chip families. It has been assailed as a “backdoor” – a term Intel emphatically rejects – and it is a mechanism targeted by researchers at UK-based Positive Technologies, who are set to reveal in detail new ways to exploit the ME next month.

The Management Engine is a barely documented black box. it has its own CPU and its own operating system – recently, an x86 Quark core and MINIX – that has complete control over the machine, and it functions below and out of sight of the installed operating system and any hypervisors or antivirus tools present.

It is designed to allow network administrators to remotely or locally log into a server or workstation, and fix up any errors, reinstall the OS, take over the desktop, and so on, which is handy if the box is so messed up it can’t even boot properly.

The ME runs closed-source remote-administration software to do this, and this code contains bugs – like all programs – except these bugs allow hackers to wield incredible power over a machine. The ME can be potentially abused by to install rootkits and other forms of spyware that silently snoop on users, steal information, or tamper with files.

SPS is based on ME, and allows you to remotely configure Intel-powered servers over the network. TXE is Intel’s hardware authenticity technology. Previously, the AMT suite of tools, again running on ME, could be bypassed with an empty credential string.

Today, Intel has gone public with more issues in its firmware. It revealed it “has identified several security vulnerabilities that could potentially place impacted platforms at risk” following an audit of its internal source code:

In response to issues identified by external researchers, Intel has performed an in-depth comprehensive security review of our Intel Management Engine (ME), Intel Server Platform Services (SPS), and Intel Trusted Execution Engine (TXE) with the objective of enhancing firmware resilience.

The flaws, according to Intel, could allow an attacker to impersonate the ME, SPS or TXE mechanisms, thereby invalidating local security features; “load and execute arbitrary code outside the visibility of the user and operating system”; and crash affected systems. The severity of the vulnerabilities is mitigated by the fact that most of them require local access, either as an administrator or less privileged user; the rest require you to access the management features as an authenticated sysadmin.

Intel ME controller chip has secret kill switch

READ MORE

But as Google security researcher Matthew Garrett pointed out in the past hour or so, the aforementioned AMT flaw, if not patched, could allow remote exploitation.

In other words, if a server or other system with the AMT hole hasn’t been updated to kill off that vulnerabilities, these newly disclosed holes will allow anyone on the network to potentially log in and execute malicious code within the powerful ME coprocessor.

“The ME compromise presumably gives you everything the AMT compromise gives you, plus more,” said Garrett via Twitter. “If you compromise the ME kernel, you compromise everything on the ME. That includes AMT, but it also includes PTT.”

He explained, “PTT is Intel’s ‘Run a TPM in software on the ME’ feature. If you’re using PTT and someone compromises your ME, the TPM is no longer trustworthy. That probably means your Bitlocker keys are compromised, but it also means all your remote attestation credentials are toast.”

Garrett said if an exploit allows unsigned data to be installed and interpreted by the ME, an attacker could effectively trigger the reinfection of malware after every ME reboot. Were that to happen, the only way to fix things would be to reflash the hardware by hand. At that point, he said, it would probably be cheaper just to get new hardware.

Thanks, Intel. pic.twitter.com/w16IyKuCtu

— The Register (@TheRegister) November 20, 2017

Intel said systems using ME Firmware versions 11.0, 11.5, 11.6, 11.7, 11.10, and 11.20, SPS Firmware version 4.0, and TXE version 3.0 are affected. The cited CVE-assigned bugs are as follows:

• Intel Manageability Engine Firmware 11.0.x.x/11.5.x.x/11.6.x.x/11.7.x.x/11.10.x.x/11.20.x.x
  • CVE-2017-5705: “Multiple buffer overflows in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5708: “Multiple privilege escalations in kernel in Intel Manageability Engine Firmware 11.0/11.5/11.6/11.7/11.10/11.20 allow unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
  • CVE-2017-5711: “Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege.” Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
  • CVE-2017-5712: “Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege.” People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
• Intel Manageability Engine Firmware 8.x/9.x/10.x
  • CVE-2017-5711: “Multiple buffer overflows in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allow attacker with local access to the system to execute arbitrary code with AMT execution privilege.” Logged-in superusers, or high-privilege programs, can execute code within the AMT suite, below the OS and any other software.
  • CVE-2017-5712: “Buffer overflow in Active Management Technology (AMT) in Intel Manageability Engine Firmware 8.x/9.x/10.x/11.0/11.5/11.6/11.7/11.10/11.20 allows attacker with remote Admin access to the system to execute arbitrary code with AMT execution privilege.” People with network access to a machine, and can log in as an admin, can execute code within the AMT suite.
• Server Platform Service 4.0.x.x
  • CVE-2017-5706: “Multiple buffer overflows in kernel in Intel Server Platform Services Firmware 4.0 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5709: “Multiple privilege escalations in kernel in Intel Server Platform Services Firmware 4.0 allows unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.
• Intel Trusted Execution Engine 3.0.x.x
  • CVE-2017-5707: “Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware 3.0 allow attacker with local access to the system to execute arbitrary code.” Logged-in superusers, or high-privilege programs, can execute code within the hidden Management Engine, below the OS and any other software.
  • CVE-2017-5710: “Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware 3.0 allows unauthorized process to access privileged content via unspecified vector.” Logged-in users or running apps can slurp confidential information out of memory. This is very bad news on a shared system.

Chipzilla thanked Mark Ermolov and Maxim Goryachy at Positive for discovering and bringing to its attention the flaw CVE-2017-5705, which sparked the aforementioned review of its source code for vulnerabilities.

Intel advises Microsoft and Linux users to download and run the Intel-SA-00086 detection tool to determine whether their systems are vulnerable to the above bugs. If you are at risk, you must obtain and install firmware updates from your computer’s manufacturer, if and when they become available. The new code was developed by Intel, but it needs to be cryptographically signed by individual hardware vendors in order for it to be accepted and installed by the engine.

Lenovo was quick off the mark with patches for its gear ready to download.

We’ll give you a roundup of fixes as soon as we can. It’s not thought Apple x86 machines are affected as they do not ship with Intel’s ME, as far as we can tell.

Today’s news will no doubt fuel demands for Intel to ship components free of its Management Engine – or provide a way to fully disable it – so people can use their PCs without worrying about security bugs on mysterious secluded coprocessors. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/20/intel_flags_firmware_flaws/

A Carnegie-Mellon CERT researcher has discovered the Microsoft broke some use-cases for its Address Space Layout Randomisation (ASLR), designed to block code-reuse attacks.

The bug is simple: as of Windows 8, a bug in Microsoft’s system-wide mandatory ASLR implementation meant applications were allocated addresses with zero entropy – in other words, they weren’t randomised. Windows 10 has the problem, too.

The bug was discovered by CERT/CC vulnerability analyst Will Dormann, and was published late last week here.

Dormann was researching why Microsoft’s equation editor opened Excel to remote code execution (fixed in last week’s patch Tuesday list) when he discovered the ASLR slip.

Here’s the summary of the bug:

Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomise executables that do not opt in to ASLR.

It’s important to note that while bad, the bug only affects a subset of applications:

• Applications using mandatory ASLR are affected;
• Applications that used opt-in ASLR aren’t affected;
• Applications that never used ASLR aren’t affected either way, of course.

The CERT/CC advisory explains that the problem introduced with Windows 8 was a change in the mandatory ASLR implementation: “system-wide mandatory ASLR is implemented via the HKLMSystemCurrentControlSetControlSession ManagerKernelMitigationOptions binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.”

The other problem was in Windows Defender Exploit Guard (and before it, the now-deprecated Enhanced Mitigation Experience Toolkit, EMET), because that’s where the developer chose whether or not to use ASLR.

However: “the default GUI value of ‘On by default’ does not reflect the underlying registry value (unset). This causes programs without /DYNAMICBASE to get relocated, but without any entropy.”

As Dormann Tweeted:

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.

Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

Or for those not proficient in setting bits in binary registry values (such as myself), either manually set the values indicated in this picture, or if you don’t care about clobbering any existing system-wide mitigations, import this .REG file:https://t.co/nOnhvU2xZF pic.twitter.com/i4YNpET0wq

— Will Dormann (@wdormann) November 16, 2017

As Dormann’s Tweet (and his Gist post) describe, sysadmins can set a registry value to force bottom-up ASLR (a wonderful task if you’re in charge of a fleet of machines); otherwise, it seems to El Reg customers would have to wait for application developers to make the change, and install an update. So far, Microsoft hasn’t published any fix. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/21/microsoft_windows_8_address_space_layout_randomisation_weakness/

A Carnegie-Mellon CERT researcher has discovered the Microsoft broke some use-cases for its Address Space Layout Randomisation (ASLR), designed to block code-reuse attacks.

The bug is simple: as of Windows 8, a bug in Microsoft’s system-wide mandatory ASLR implementation meant applications were allocated addresses with zero entropy – in other words, they weren’t randomised. Windows 10 has the problem, too.

The bug was discovered by CERT/CC vulnerability analyst Will Dormann, and was published late last week here.

Dormann was researching why Microsoft’s equation editor opened Excel to remote code execution (fixed in last week’s patch Tuesday list) when he discovered the ASLR slip.

Here’s the summary of the bug:

Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomise executables that do not opt in to ASLR.

It’s important to note that while bad, the bug only affects a subset of applications:

• Applications using mandatory ASLR are affected;
• Applications that used opt-in ASLR aren’t affected;
• Applications that never used ASLR aren’t affected either way, of course.

The CERT/CC advisory explains that the problem introduced with Windows 8 was a change in the mandatory ASLR implementation: “system-wide mandatory ASLR is implemented via the HKLMSystemCurrentControlSetControlSession ManagerKernelMitigationOptions binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.”

The other problem was in Windows Defender Exploit Guard (and before it, the now-deprecated Enhanced Mitigation Experience Toolkit, EMET), because that’s where the developer chose whether or not to use ASLR.

However: “the default GUI value of ‘On by default’ does not reflect the underlying registry value (unset). This causes programs without /DYNAMICBASE to get relocated, but without any entropy.”

As Dormann Tweeted:

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.

Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

Or for those not proficient in setting bits in binary registry values (such as myself), either manually set the values indicated in this picture, or if you don’t care about clobbering any existing system-wide mitigations, import this .REG file:https://t.co/nOnhvU2xZF pic.twitter.com/i4YNpET0wq

— Will Dormann (@wdormann) November 16, 2017

As Dormann’s Tweet (and his Gist post) describe, sysadmins can set a registry value to force bottom-up ASLR (a wonderful task if you’re in charge of a fleet of machines); otherwise, it seems to El Reg customers would have to wait for application developers to make the change, and install an update. So far, Microsoft hasn’t published any fix. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/21/microsoft_windows_8_address_space_layout_randomisation_weakness/

A security expert found a way to work around Microsoft’s Address Space Randomization Layer, which protects the OS from memory-based attacks.

The latest versions of Microsoft Windows are vulnerable to attacks due to a newly discovered vulnerability in Address Space Layout Randomization (ASLR).

The vulnerability affects Windows 8, Windows 8.1, and Windows 10 systems with system-wide ASLR enabled via Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) or Windows Defender Exploit Guard.

Will Dormann, a senior vulnerability analyst at Carnegie Mellon’s CERT-CC discovered and reported the vulnerability. System-wide mandatory ASLR on all affected systems, enabled via EMET, has zero entropy, “essentially making it worthless,” he explained on Twitter.

His discovery means an attacker can more easily exploit memory corruption vulnerabilities in Windows 8 and newer systems, which ASLR would normally protect. The advantage of ASLR is it makes exploiting memory corruption bugs more difficult; however, it isn’t working as intended.

ASLR arrived in Windows Vista to prevent code-reuse attacks, which rely on code executing at predictable memory locations, by loading executable modules at random addresses. Starting in Windows 8, Microsoft began to offer system-wide mandatory ASLR. Admins could enable programs to randomize locations even for applications without ASLR support.

EMET is a free tool Microsoft previously released to protect applications not opted into ASLR and other exploit mitigation tools. Admins could enable them through the EMET interface. When Microsoft launched the Windows 10 Fall Creators Update, it integrated EMET’s key capabilities into the Windows Defender Exploit Guard.

Exploit Guard has an option to enable system-wide bottom-up ASLR. However, as Dormann discovered, setting system-wide ASLR in Windows, Windows 8.1, and Windows 10 does not actually randomize memory locations. If the default GUI in Exploit Guard says “On by default,” programs will still be relocated, but to the same address across different reboots and systems.

This could lead to a “wide variety” of common types of attacks, explains a DHS spokesman.

People who believe they are protected by ASLR may take risks they wouldn’t normally take; for example, opening an attachment in an unsolicited message. If the message is a spearphish and ASLR is working properly, the exploit would fail. However, without ASLR, the attacker could gain complete control of the victim’s system and view their access to other systems.

Microsoft says the problem is not a flaw. It says the issue, discovered by CMU’s CERT/CC and reported by US-CERT, is with configuring non-default settings for ASLR using Exploit Guard and EMET, and providing workarounds. The company is investigating and will address the configuration issue.

“The issue described by the US CERT is not a vulnerability,” a Microsoft spokesperson says. “ASLR is functioning as designed and customers running default configurations of Windows are not at increased risk.”

CERT/CC is currently unaware of a practical solution to the problem, Dormann says, adding a workaround for administrators in his blog post on the discovery. He advises enabling both bottom-up and mandatory ASLR system-wide for all systems running Windows 8 or later, using a certain registry value. Businesses should also use defense-in-depth strategies to protect networks, users, and data from unauthorized access, he adds.

Related Content:

• North Korea’s Lazarus Group Evolves Tactics, Goes Mobile
• Terdot Banking Trojan Spies on Email, Social Media
• Forget APTs: Let’s Talk about Advanced Persistent Infrastructure
• White House Releases New Charter for Using, Disclosing Security Vulnerabilities

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Kelly Sheridan is Associate Editor at Dark Reading. She started her career in business tech journalism at Insurance Technology and most recently reported for InformationWeek, where she covered Microsoft and business IT. Sheridan earned her BA at Villanova University. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/researcher-finds-hole-in-windows-aslr-security-defense/d/d-id/1330466?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A security expert found a way to work around Microsoft’s Address Space Randomization Layer, which protects the OS from memory-based attacks.

The latest versions of Microsoft Windows are vulnerable to attacks due to a newly discovered vulnerability in Address Space Layout Randomization (ASLR).

The vulnerability affects Windows 8, Windows 8.1, and Windows 10 systems with system-wide ASLR enabled via Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) or Windows Defender Exploit Guard.

Will Dormann, a senior vulnerability analyst at Carnegie Mellon’s CERT-CC discovered and reported the vulnerability. System-wide mandatory ASLR on all affected systems, enabled via EMET, has zero entropy, “essentially making it worthless,” he explained on Twitter.

His discovery means an attacker can more easily exploit memory corruption vulnerabilities in Windows 8 and newer systems, which ASLR would normally protect. The advantage of ASLR is it makes exploiting memory corruption bugs more difficult; however, it isn’t working as intended.

ASLR arrived in Windows Vista to prevent code-reuse attacks, which rely on code executing at predictable memory locations, by loading executable modules at random addresses. Starting in Windows 8, Microsoft began to offer system-wide mandatory ASLR. Admins could enable programs to randomize locations even for applications without ASLR support.

EMET is a free tool Microsoft previously released to protect applications not opted into ASLR and other exploit mitigation tools. Admins could enable them through the EMET interface. When Microsoft launched the Windows 10 Fall Creators Update, it integrated EMET’s key capabilities into the Windows Defender Exploit Guard.

Exploit Guard has an option to enable system-wide bottom-up ASLR. However, as Dormann discovered, setting system-wide ASLR in Windows, Windows 8.1, and Windows 10 does not actually randomize memory locations. If the default GUI in Exploit Guard says “On by default,” programs will still be relocated, but to the same address across different reboots and systems.

This could lead to a “wide variety” of common types of attacks, explains a DHS spokesman.

People who believe they are protected by ASLR may take risks they wouldn’t normally take; for example, opening an attachment in an unsolicited message. If the message is a spearphish and ASLR is working properly, the exploit would fail. However, without ASLR, the attacker could gain complete control of the victim’s system and view their access to other systems.

Microsoft says the problem is not a flaw. It says the issue, discovered by CMU’s CERT/CC and reported by US-CERT, is with configuring non-default settings for ASLR using Exploit Guard and EMET, and providing workarounds. The company is investigating and will address the configuration issue.

“The issue described by the US CERT is not a vulnerability,” a Microsoft spokesperson says. “ASLR is functioning as designed and customers running default configurations of Windows are not at increased risk.”

CERT/CC is currently unaware of a practical solution to the problem, Dormann says, adding a workaround for administrators in his blog post on the discovery. He advises enabling both bottom-up and mandatory ASLR system-wide for all systems running Windows 8 or later, using a certain registry value. Businesses should also use defense-in-depth strategies to protect networks, users, and data from unauthorized access, he adds.

Related Content:

• North Korea’s Lazarus Group Evolves Tactics, Goes Mobile
• Terdot Banking Trojan Spies on Email, Social Media
• Forget APTs: Let’s Talk about Advanced Persistent Infrastructure
• White House Releases New Charter for Using, Disclosing Security Vulnerabilities

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Kelly Sheridan is Associate Editor at Dark Reading. She started her career in business tech journalism at Insurance Technology and most recently reported for InformationWeek, where she covered Microsoft and business IT. Sheridan earned her BA at Villanova University. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/researcher-finds-hole-in-windows-aslr-security-defense/d/d-id/1330466?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

US Federal Communications Commission (FCC) Commissioner Jessica Rosenworcel asks us to picture this…

You and your family are sitting down to dinner. It’s a sacred slice of your busy day: a “reprieve from the unrelenting chaos and hubbub of everyday life.” She knows it well, she says, because it’s true for her family, just like as with so many others.

But then, like clockwork, that happy time gets shattered by the ringing of a phone. Who could it be? Why, it’s “Rachel from cardmember services.” Or gosh, it’s someone claiming to be from the IRS – you owe back taxes! Or hey, how about this: you’ve been selected to receive a line of low-interest credit for small businesses. Or golly, a cruise!

Gosh, honey, don’t pass me the mashed potatoes yet. Sweetie, I’ll have to hear about your science fair project later. This call is important: it’s from an important robot!

…said no one ever.

All those shattered evenings are why the FCC on Thursday unanimously passed (PDF) a resolution that lets phone carriers block illegal robocalls.

The new rules enable voice service providers to block certain calls before they get to our phones, the FCC said in its ruling. Specifically, providers now have the go-ahead to block calls from phone numbers on a Do-Not-Originate (DNO) list and spoofed calls: those numbers that show up in Caller ID that are “invalid, unallocated, or unused numbers.”

In other words, service providers will now be able to block calls from numbers with tell-tale signs that they’re fraudulent: for example, numbers with area codes that don’t exist or that can’t make outgoing calls.

Such calls are probably up to no good, FCC Chairman Ajit Pai said in a statement (PDF):

These calls are very likely to be illegal or fraudulent; there’s no legitimate reason for anyone to spoof caller ID to make it seem as if he or she is calling from an unassigned or invalid phone number.

It’s understandable if your first thought is deja vu: hasn’t the FCC already enabled carriers to block these calls?

No, though both the FCC and the Federal Trade Commission have been fighting against robocalls for years. A few years ago, the FTC said it was going to name and shame robocallers, for one.

Hefty sanctions on robocallers have hit the headlines, while FTC competitions to find new technological solutions have uncovered some innovative thinking.

The big tech players are also trying to fight robocalls: Last year, Google added “do-not-answer-that!!” robocall warnings on its Phone app on Nexus and AndroidOne devices, so as to warn about potential spam callers and give users the ability to block and report spammy numbers.

But still, the robocalls keep coming. The FCC notes that one of the most pernicious of this ilk are robocalls placed by scammers, including IRS scams that are out to steal consumers’ cash or their identities.

A typical IRS scam is one in which robocallers pretend to be representing the IRS and claim the called party owes back taxes. IRS scams are particularly deceptive if the illegal robocaller can spoof the number so the Caller ID display makes it look like the call is really, truly coming from the IRS. Another scam involves crooks trying to trick people by claiming a young family member is in jail and needs bail money. The FCC says that since 1 August 2016, it’s received nearly 185,000 complaints about calls that consumers didn’t want.

What effect will this move have on legally spoofed calls? As RoboKiller’s Ethan Garr has noted, reasons to spoof a calling number do exist:

Many of the calls you receive are legitimately spoofed for very good reasons – when you get a call from an extension at your bank, but your caller ID shows the bank’s main number, for example, it came through a PBX, and that is a “spoofed” call.

Other legal reasons to spoof a phone number include when people have legitimate reasons to hide their information: for example, it’s legal to spoof numbers of investigators working on cases, of victims of domestic abuse, or of doctors who need to discuss private medical matters.

The newly passed proposal shouldn’t affect these legal spoofs. Under the FCC’s Truth in Caller ID Act, spoofing is only illegal when it’s done to defraud, cause harm or wrongly obtain anything of value. Breaking the law can rack up fines of up to $10,000 per violation.

The FCC’s new resolution to allow carriers to block robocalls might be a step in the right direction, but it’s got some strings attached. Specifically, our wallet strings, given that the proposal doesn’t stop carriers from charging us for the luxury of not being pestered and scammed.

Commissioner Rosenworcel, who voted to approve the proposal but says it didn’t go far enough, had this to say in a statement (PDF):

While the agency offers carriers the ability to limit calls from what are likely to be fraudulent actors, it fails to prevent them from charging consumers for this service. So this is the kicker: the FCC takes action to ostensibly reduce robocalls but then makes sure you can pay for the privilege. If you ask me, that’s ridiculous.

Follow @LisaVaas
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/Iam3Y2SgpPE/