SWFTools commit 772e55a2 was discovered to contain a stack overflow via ImageStream::getPixel(unsigned char*) at /xpdf/Stream.cc.

    ./pdf2swf -G -f -t [sample file] -o /dev/null
    

    ==43189==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffe33ffbdc4 at pc 0x00000060df33 bp 0x7ffe33ffbc50 sp 0x7ffe33ffbc48
    WRITE of size 1 at 0x7ffe33ffbdc4 thread T0
        #0 0x60df32 in ImageStream::getPixel(unsigned char*) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Stream.cc:348:12
        #1 0x7c9dc5 in VectorGraphicOutputDev::drawGeneralImage(GfxState*, Object*, Stream*, int, int, GfxImageColorMap*, int, int, int, int*, Stream*, int, int, int, GfxImageColorMap*) /home/bupt/Desktop/swftools/lib/pdf/VectorGraphicOutputDev.cc:1303:12
        #2 0x7ccc45 in VectorGraphicOutputDev::drawImage(GfxState*, Object*, Stream*, int, int, GfxImageColorMap*, int*, int) /home/bupt/Desktop/swftools/lib/pdf/VectorGraphicOutputDev.cc:1430:5
        #3 0x71dc57 in Gfx::doImage(Object*, Stream*, int) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Gfx.cc:3664:12
        #4 0x6ec5e0 in Gfx::opXObject(Object*, int) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Gfx.cc:3336:7
        #5 0x705f02 in Gfx::execOp(Object*, Object*, int) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Gfx.cc:693:3
        #6 0x7049c1 in Gfx::go(int) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Gfx.cc:584:7
        #7 0x703ea8 in Gfx::display(Object*, int) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Gfx.cc:556:3
        #8 0x6b9401 in Page::displaySlice(OutputDev*, double, double, int, int, int, int, int, int, int, int, Catalog*, int (*)(void*), void*) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Page.cc:317:10
        #9 0x6b8cee in Page::display(OutputDev*, double, double, int, int, int, int, Catalog*, int (*)(void*), void*) /home/bupt/Desktop/swftools/lib/pdf/xpdf/Page.cc:264:3
        #10 0x6099b0 in PDFDoc::displayPage(OutputDev*, int, double, double, int, int, int, int, int (*)(void*), void*) /home/bupt/Desktop/swftools/lib/pdf/xpdf/PDFDoc.cc:317:27
        #11 0x5f87d5 in render2(_gfxpage*, _gfxdevice*, int, int, int, int, int, int) /home/bupt/Desktop/swftools/lib/pdf/pdf.cc:164:14
        #12 0x5f8e64 in pdfpage_rendersection(_gfxpage*, _gfxdevice*, double, double, double, double, double, double) /home/bupt/Desktop/swftools/lib/pdf/pdf.cc:190:5
        #13 0x501816 in main /home/bupt/Desktop/swftools/src/pdf2swf.c:832:3
        #14 0x7f6be3d6fc86 in __libc_start_main /build/glibc-CVJwZb/glibc-2.27/csu/../csu/libc-start.c:310
        #15 0x420b99 in _start (/home/bupt/Desktop/swftools/build/bin/pdf2swf+0x420b99)
    
    Address 0x7ffe33ffbdc4 is located in stack of thread T0 at offset 292 in frame
        #0 0x7c774f in VectorGraphicOutputDev::drawGeneralImage(GfxState*, Object*, Stream*, int, int, GfxImageColorMap*, int, int, int, int*, Stream*, int, int, int, GfxImageColorMap*) /home/bupt/Desktop/swftools/lib/pdf/VectorGraphicOutputDev.cc:1127
    
      This frame has 19 object(s):
        [32, 40) 'x1' (line 1130)
        [64, 72) 'y1' (line 1130)
        [96, 104) 'x2' (line 1130)
        [128, 136) 'y2' (line 1130)
        [160, 168) 'x3' (line 1130)
        [192, 200) 'y3' (line 1130)
        [224, 232) 'x4' (line 1130)
        [256, 264) 'y4' (line 1130)
        [288, 292) 'pixBuf' (line 1132) <== Memory access at offset 292 overflows this variable
        [304, 316) 'rgb' (line 1133)
        [336, 416) 'color_transform' (line 1137)
        [448, 456) 'buf' (line 1146)
        [480, 736) 'pal' (line 1151)
        [800, 804) 'gray' (line 1155)
        [816, 824) 'buf94' (line 1188)
        [848, 856) 'buf173' (line 1228)
        [880, 1904) 'pal179' (line 1231)
        [2032, 2044) 'rgb180' (line 1232)
        [2064, 3088) 'pal486' (line 1340)
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/bupt/Desktop/swftools/lib/pdf/xpdf/Stream.cc:348:12 in ImageStream::getPixel(unsigned char*)
    Shadow bytes around the buggy address:
      0x1000467f7760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x1000467f7770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x1000467f7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x1000467f7790: 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2
      0x1000467f77a0: 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2
    =>0x1000467f77b0: 00 f2 f2 f2 00 f2 f2 f2[04]f2 00 04 f2 f2 00 00
      0x1000467f77c0: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f8 f2 f2 f2
      0x1000467f77d0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x1000467f77e0: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
      0x1000467f77f0: f2 f2 f2 f2 f2 f2 f2 f2 f8 f2 f8 f2 f2 f2 f8 f2
      0x1000467f7800: f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==43189==ABORTING
    

    SUMMARY: AddressSanitizer: stack-buffer-overflow /home/bupt/Desktop/swftools/lib/pdf/xpdf/Stream.cc:348:12 in ImageStream::getPixel(unsigned char*)

CVE-2022-35099: Poc/CVE-2022-35099.md at main · Cvjark/Poc

This vulnerability exists in Tacitine Firewall, all versions of EN6200-PRIME QUAD-35 and EN6200-PRIME QUAD-100 between 19.1.1 to 22.20.1 (inclusive), due to improper control of code generation in the Tacitine Firewall web-based management interface. An unauthenticated remote attacker could exploit this vulnerability by sending a specially crafted http request on the targeted device. Successful exploitation of this vulnerability could allow an unauthenticated remote attacker to execute arbitrary commands on the targeted device.

%PDF-1.7 %���� 1 0 obj <>/Metadata 71 0 R/ViewerPreferences 72 0 R>> endobj 2 0 obj <> endobj 3 0 obj <>/ExtGState<>/XObject<>/ProcSet\[/PDF/Text/ImageB/ImageC/ImageI\] >>/Annots\[ 22 0 R\] /MediaBox\[ 0 0 612 792\] /Contents 4 0 R/Group<>/Tabs/S/StructParents 0>> endobj 4 0 obj <> stream x��\[�r�F}W��a�T4�\\ps�\\+Kv��8v$:��M� �P! ���ﷻi���p�@ �>���=��|U�٤b/\_�Ϋ\*�<�S�i4.�����|�!{(YU������S?��4\_�z�^\_^��NO�TH�>�T�U~z��������d�V0!x�����D�u,�<���:�a��s��=��쁎���ӓO��\`�����'�vz�Ϣ\]d�'%Yhk�G�@�޼�\`#��\_�UU��z\[����:�������aY��KF��Q1Ov ��4�5�/�4�l��s5��\]�̹��2��.%�E�< ���\[�X���F7�l�H�\]\\\]�\`�K�x\`^�8�x��Q�ըQ����d�>@�@@�/��$��^p�k�4��p8�-��aׯ���\_yo���yQi+��:s$DW6!W�L�Nϔ��{�L{�~�+8�����+f�/�����W����8gx��w|�G��T\\�#kFʈ'�E�|�I�JT(��^O�yb�4T$aU�+yI�El��wu� f�\*���ʨ��:������cOk��ޛ��Ɇ��(����q��h�o��}-�,��Nm�8@�\_d��LnU�ܷ�Dǀ���"�\_@.Шٌ����� &F�-e�K�!��:�?��79޸�C�!�����O�9Hѹ~D��cǙ%Jx l����5+��#H�\]OME�~�P���zf��k�w�� "2Ń� �OX1�hc�� �7��8�ŕ\`(�2� \`��(!� \_'\]۔h�{���gr�U�89e

CVE-2022-40628

Manufacturers need to document a medical device's intended use and operational environment, as well as plan for misuse, such as a cyberattack.

Due to the increasing concerns about medical devices' cybersecurity risks, European Union regulators put forward a new set of market entry requirements for medical devices and in vitro diagnostic medical devices to reduce the risk of patient harm as a result of a cyber incident, as well as protect national health systems.

EU regulators are raising the bar on cybersecurity requirements with the European Union Medical Device Regulation (MDR) and the European Union In Vitro Diagnostic Regulation (IVDR), which went into effect May 26, 2021. The regulations are intended to "establish a robust, transparent, predictable and sustainable regulatory framework ... which ensures a high level of safety and health whilst supporting innovation."

Organizations have until May 26, 2024, or when their current market certification expires, to make the necessary changes to their quality management systems and technical documentation to comply with the new requirements. Despite the number of assessment processes and standards and guidance documents that have been provided, medical device manufacturers, providers, and certification services may not be ready in time.

More than 90% of currently valid AIMDD/MDD certificates will expire by 2024, so a significant number of existing devices need to be reapproved, in addition to new devices entering the market. It is estimated that 85% of products currently on the market today still require new certification under MDR.IVDR. Considering that the process takes 13 to 18 months, companies need to start the process now in order to meet the 2024 deadline.

**Setting Instructions for Use**

In general, cybersecurity processes are not that different from general device performance and safety processes. The goal is to assure (through verification and validation) and demonstrate (through documentation) device performance, risk reduction and control, and minimization of foreseeable risks and undesirable side effects through risk management. Combination products or interconnected devices/systems also require management of the risks that result from interaction between software and the IT environment.

The Medical Device Coordination Group's MDCG-16 Guidance on Cybersecurity for medical devices explains how to interpret and fulfill cybersecurity requirements under MDR and IVDR. Manufacturers are expected to take into account the principles of the secure development life cycle, security risk management, and verification and validation. Further, they should provide minimum IT requirements and expectations for cybersecurity processes, such as installation and maintenance in their device's instructions for use. "Instructions for use" is a highly structured required section of the certification application manufacturers must file.

Cybersecurity measures must reduce any risks associated with the operation of medical devices, including cybersecurity-induced safety risks, to provide a high level of protection for health and safety. The International Electrotechnical Commission (IEC) spells out high-level security features, best practices, and security levels in IEC/TIR 60601-4-5. Another IEC technical report, IEC 80001-2-2, enumerates specific design and architecture security capabilities, such as automatic logoff, audit controls, data backup and disaster recovery, malware detection/protection, and system and OS hardening.

To meet ISO guidelines (ISO 14971), the Association for the Advancement of Medical Instrumentation advises striking a balance between safety and security. Careful analysis is required to prevent security measures from compromising safety and safety measures from becoming a security risk. Security needs to be right-sized and should be neither too weak nor too restrictive.

**Sharing Responsibility for Cybersecurity**

Cybersecurity is a responsibility shared between the device manufacturer and the deploying organization (typically the customer/operator). Thus, specific roles that provide important cybersecurity functions — such as integrator, operator, healthcare and medical professionals, and patients and consumers — require careful training and documentation.

The "instructions for use" section of a manufacturer's certification application should provide cybersecurity processes including security configuration options, product installation, initial configuration guidelines (e.g., change of default password), instructions for deploying security updates, procedures for using the medical device in failsafe mode (e.g., enter/exit failsafe mode, performance restrictions in fail-safe mode, and data recovery function when resuming normal operation), and action plans for the user in case of an alert message.

That section should also provide user requirements for training and enumerate required skills, including IT skills required for the installation, configuration, and operation of the medical device. In addition, it should specify requirements for the operating environment (hardware, network characteristics, security controls, etc.) that cover assumptions on the environment of use, risks for device operation outside the intended operating environment, minimum platform requirements for the connected medical device, recommended IT security controls, and backup and restore features for both data and configuration settings.

Specific security information may be shared through documentation other than the instructions for use, such as instructions for administrators or security operation manuals. Such information may include a list of IT security controls included in the medical device, provisions to ensure integrity/validation of software updates and security patches, technical properties of hardware components, the software bill of materials, user roles and associated access privileges/permissions on the device, logging function, guidelines on security recommendations, requirements for integrating the medical device into a health information system, and a list of the network data streams (protocol types, origin/destination of data streams, addressing scheme, etc.).

If the operating environment is not exclusively local but involves external hosting providers, the documentation must clearly state what, where (in consideration of data-residency laws), and how data is stored, as well as any security controls to safeguard the data in the cloud environment (e.g., encryption). The instructions for use section of the documentation needs to provide specific configuration requirements for the operating environment, such as firewall rules (ports, interfaces, protocols, addressing schemes, etc.).

Security controls implemented during premarket activities may be inadequate to maintain an acceptable benefit-risk level during the operational life of the device. Therefore, regulations require the manufacturer to establish a post-market cybersecurity surveillance program to monitor operation of the device in the intended environment; to share and disseminate cybersecurity information and knowledge of cybersecurity vulnerabilities and threats across multiple sectors; to perform vulnerability remediation; and to plan for incident response.

The manufacturer is further responsible for investigating and reporting serious incidents and fielding safety corrective actions. Specifically, incidents that have cybersecurity-related root causes are subject to trend reporting, including any statistically significant increase in the frequency or severity of incidents.

**Planning for All Scenarios**

Today's medical devices are highly integrated and operate in a complex network of devices and systems, many of which may not be under control of the device operator. Therefore, manufacturers should carefully document the device's intended use and intended operational environment, as well as plan for reasonably foreseeable misuse, such as a cyberattack.

Cybersecurity pre- and post-market risk management requirements and supporting activities are not necessarily different from traditional safety programs. However, they do add an additional level of complexity as:

*   The range of risks to consider is more complex (safety, privacy, operations, business). 
*   They require a specific set of activities that need to be conducted along the device development life cycle via a Secure Product Development Framework (SPDF).

Global regulators, including MDR/IVDR, are starting to enforce a higher level of security for medical devices and specifically requiring demonstrable security as part of the larger device life cycle. Devices should meet, based on device type and use case, a security baseline, and manufacturers need to maintain that baseline over the entire lifetime of the device.

How Europe Is Using Regulations to Harden Medical Devices Against Attack

A new wave of a mobile surveillance campaign has been observed targeting the Uyghur community as part of a long-standing spyware operation active since at least 2015, cybersecurity researchers disclosed Thursday.
The intrusions, originally attributed to a threat actor named Scarlet Mimic back in January 2016, is said to have encompassed 20 different variants of the Android malware, which were

A new wave of a mobile surveillance campaign has been observed targeting the Uyghur community as part of a long-standing spyware operation active since at least 2015, cybersecurity researchers disclosed Thursday.

The intrusions, originally attributed to a threat actor named Scarlet Mimic back in January 2016, is said to have encompassed 20 different variants of the Android malware, which were disguised as book, pictures, and an audio version of the Quran.

The malware, while relatively unsophisticated from a technical standpoint, comes with extensive capabilities to steal sensitive data from an infected device, send SMS messages on the victim's behalf, make phone calls, and track their locations.

Additionally, it allows the recording of incoming and outgoing phone calls as well as surrounding audio.

"All this makes it a powerful and dangerous surveillance tool," Israeli cybersecurity firm Check Point said in a technical deepdive, calling the spyware **MobileOrder**.

It's worth noting that a part of the campaign was recently disclosed by researchers from the MalwareHunterTeam and Cyble, in which a book written by the exiled Uyghur leader Dolkun Isa was used as a lure to deliver the malware.

Check Point said it observed MobileOrder artifacts in the wild right from 2015 to mid-August 2022, with the exception of 2021, when none were detected.

Attack campaigns likely involve the use of social engineering tactics to trick unsuspecting victims into launching malicious applications that reference seemingly innocuous documents, photos, and audio files.

These apps contain a variety of baits, including a PDF about guerrilla warfare and pictures related to the deployment of paramilitary forces in Ürümqi, the capital of the Xinjiang Uyghur Autonomous Region, in the aftermath of the deadly April 2014 attack.

Opening the rogue app, in turn, launches a decoy document designed to distract the target from noticing the malicious actions in the background.

"Some of the versions also ask for Device Admin and root access, which not only gives the malware full access to the device, but also prevents the victim from easily uninstalling the application," the researchers said.

Other features supported by MobileOrder include executing a remote shell and even dropping additional Android Package (APK) files.

The campaign's attribution to Scarlet Mimic, per Check Point, stems from clear code overlaps, shared infrastructure, and the same victimology patterns.

Furthermore, the ongoing use of MobileOrder signals a shift in attack vector from desktop to mobile surveillance, what with the actor previously linked to a Windows malware called Psylo Trojan.

While it's not clear which of these attacks throughout the past seven years have been successful, the very fact that the malware authors are continuing to deploy the spyware is an indication that some of these efforts have paid off.

"The persistence of the campaign, the evolution of the malware and the persistent focus on targeting specific populations indicate that the group's operations over the years are successful to some extent," Check Point said.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Researchers Uncover Years-Long Mobile Spyware Campaign Targeting Uyghurs

The tactic is just one in a constantly expanding bag of tricks that attackers are using to get users to click on links and open malicious documents.

A malicious campaign targeting Internet users in Slovakia is serving up another reminder of how phishing operators frequently leverage legitimate services and brands to evade security controls.

In this instance, the threat actors are taking advantage of a LinkedIn Premium feature called Smart Links to direct users to a phishing page for harvesting credit card information. The link is embedded in an email purportedly from the Slovakian Postal Service and is a legitimate LinkedIn URL, so secure email gateways (SEGs) and other filters are often unlikely to block it.

"In the case that Cofense found, attackers used a trusted domain like LinkedIn to get past secure email gateways," says Monnia Deng, director of product marketing at Bolster. "That legitimate link from LinkedIn then redirected the user to a phishing site, where they went to great lengths to make it seem legitimate, such as adding a fake SMS text message authentication."

The email also asks the recipient to pay a believably small amount of money for a package that is apparently pending shipment to them. Users tricked into clicking on the link arrive at a page designed to appear like one the postal service uses to collect online payments. But instead of merely paying for the supposed package shipment, users end up giving away their entire payment card details to the phishing operators as well.

**Not the First Tine Smart Links Feature Has Been Abused**

The campaign is not the first time that threat actors have abused LinkedIn's Smart Links feature — or Slinks, as some call it — in a phishing operation. But it marks one of the rare instances where emails containing doctored LinkedIn Slinks have ended up in user inboxes, says Brad Haas, senior intelligence analyst at Cofense. The phishing protection services vendor is currently tracking the ongoing Slovakian campaign and this week issued a report on its analysis of the threat so far.

LinkedIn's Smart Links is a marketing feature that lets users who are subscribed to its Premium service direct others to content the sender want them to see. The feature allows users to use a single LinkedIn URL to point users to multiple marketing collateral — such as documents, Excel files, PDFs, images, and webpages. Recipients receive a LinkedIn link that, when clicked, redirects them to the content behind it. LinkedIn Slinks allows users to get relatively detailed information on who might viewed the content, how they might have interacted with it, and other details.

It also gives attackers a convenient — and very credible — way to redirect users to malicious sites. 

"It's relatively easy to create Smart Links," Haas says. "The main barrier to entry is that it requires a Premium LinkedIn account," he notes." A threat actor would need to purchase the service or gain access to a legitimate user's account. But besides that, it's relatively easy for threat actors to use these links to send users to malicious sites, he says. "We have seen other phishing threat actors abuse LinkedIn Smart Links, but as of today, it's uncommon to see it reaching inboxes."

**Leveraging Legitimate Services**

The growing use by attackers of legitimate software-as-a-service and cloud offerings such LinkedIn, Google Cloud, AWS, and numerous others to host malicious content or to direct users to it, is one reason why phishing remains one of the primary initial access vectors.

Just last week, Uber experienced a catastrophic breach of its internal systems after an attacker social engineered an employee's credentials and used them to access the company's VPN. In that instance, the attacker — who Uber identified as belonging to the Lapsus$ threat group — tricked the user into accepting a multifactor authentication (MFA) request by pretending to be from the company's IT department.

It's significant that attackers are leveraging social media platforms as a proxy for their fake phishing websites. Also troubling is the fact that phishing campaigns have evolved significantly to not only be more creative but also more accessible to people who can’t write code, Deng adds.

"Phishing occurs anywhere you can send or receive a link," adds Patrick Harr, CEO at SlashNext. Hackers are wisely using techniques that avoid the most protected channels, like corporate email. Instead, they are opting to use social media apps and personal emails as a backdoor into the enterprise. "Phishing scams continue to be a serious problem for organizations, and they are moving to SMS, collaboration tools, and social," Harr says. He notes that SlashNext has seen an increase in requests for SMS and messaging protection as compromises involving text messaging becomes a bigger problem.

Threat Actor Abuses LinkedIn's Smart Links Feature to Harvest Credit Cards

In Keylime before 6.3.0, current keylime installer installs the keylime.conf file, which can contain sensitive data, as world-readable.

**oss-sec mailing list archives**

_From_: Matthias Gerstner <mgerstner () suse de>  
_Date_: Fri, 28 Jan 2022 13:57:23 +0100  

Hello list,

I have been reviewing the Keylime TPM remote attestation solution \[1\]
which resulted in a number of security related findings, including an
arbitrary remote code execution in the Keylime Agent component. The
upstream project published security advisories, fixes and an update
strategy to Keylime version 6.3.X today. Please find the details in the
following full report:

1) Scope of Review
==================

I've been looking into the four main components of Keylime: the Agent,
Registrar, Verifier and Tenant applications. I have been looking into
version 6.2.0. Any source code locations mentioned in this report relate
to this version.

2) Findings in the Agent Component
==================================

a) \`check\_mounted()\` Function Logic can be Fooled by Unprivileged Mounts (CVE-2022-23948)
-----------------------------------------------------------------------------------------

The \`check\_mounted()\` function in \`secure\_mount.py\` attempts to make
sure that a "secure" tmpfs is mounted at \`/var/lib/keylime/secure\` to
store sensitive data on that never gets written to disk. To do so the
function parses the output of the \`mount\` utility to determine whether
this file system is already mounted at the desired location.

There can exist the possibility of unprivileged users performing certain
mount operations, one of the most prominent examples being the
\`fusermount\` setuid-root binary for mounting FUSE file systems. In view
of this, parsing mount table output needs prudence. I described the
basic issue previously already in another report \[2\].

The following is a reproducer using \`fusermount\` that shows the basic local
attack vector:

    user$ export \_FUSE\_COMMFD=0
    user$ fusermount some/path/ -ononempty,fsname="tmpfs on /var/lib/keylime/secure"

This will fool the parsing logic in \`check\_mounted()\` and thus the
function assumes that the "secure" tmpfs is already mounted, while it
actually isn't.  Thus this will allow a local attacker on the system to
prevent this security feature to be effective, \*if\* the local attacker
manages to create such a mount entry before the \`keylime\_agent\` is
starting up.

The attack vector can also be used to perform a local DoS against
\`keylime\_agent\` by claiming a different \`fsname\` than tmpfs.
\`check\_mounted()\` will throw an Exception in this case and the Agent
won't start.

On a side note there are calls to \`secure\_mount.mount()\` spread
throughout the Keylime codebase (for example three times in
\`keylime\_agent.py\`, two times in \`tpm\_main.py\` and two times in
\`ca\_impl\_cfssl.py\`. There is no code to \*clean up\* this mount again,
however. So it potentially leaves behind a stale mount after services
are shutdown. Furthermore, if multiple Keylime processes should operate
in parallel this could result in a race condition where the "secure"
tmpfs is mounted twice, in the worst case mounting a fresh tmpfs over
previously stored content there.

My recommendation is to parse the \`/proc/self/mountinfo\` pseudo file for
mount table information instead. Whitespace is specially encoded in this
file. Furthermore the responsibility of mounting and unmounting this
file system should be more clearly defined during startup/shutdown of
processes and maybe a reference counting / locking scheme to prevent
race conditions should be used.

### Upstream Security Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-wj36-qcfg-5j52

### Upstream Fixes

https://github.com/keylime/keylime/commit/1a4f31a6368d651222683c9debe7d6832db6f607
https://github.com/keylime/keylime/commit/d37c406e69cb6689baa2fb7964bad75209703724

b) Possible Information Leaks via Unauthenticated Agent Quote Interface
-----------------------------------------------------------------------

A TPM quote can be requested without authentication from the Agent service via
the network:

    $ curl "keyagent-host:9002/?api\_version=500&quotes=myquote&nonce=mynonce"
    {
        "code": 200,
        "status": "Success",
        "results": {
            "quote": <base64-data>, "hash\_alg": "sha256", "enc\_alg": "rsa", "sign\_alg": "rsassa",
            "pubkey": <PEM key>", "boottime": 1639999864
        }
    }

This exposes for example the \*boottime\* of the host where the Agent is
running, information that is not otherwise easily publicly available.
Furthermore: Could the contents of the TPM quote data also be
interesting data? Could it for example allow deductions about which kind
of operating system kernel is running on the host?

I recommend to somehow authenticate and cryptographically secure this
Agent interface to prevent information leaks of this kind.

### Upstream Fixes

This issue did not receive a dedicated CVE and fix. It is covered
together with the following issue 2.c).

c) Arbitrary Remote Code Execution in the Agent via Unauthenticated Bootstrap Interface (CVE-2021-43310)
--------------------------------------------------------------------------------------------------------

Note that this issue has been discovered in parallel also by Thore
Sommer, a Keylime upstream developer.

It looks like it is possible to simply post arbitrary new values for the
U and V key parts and provide a new configuration payload to the Agent,
only knowing the Agent's UUID. The Agent's UUID can be public or
semi-public information like when \`agent\_uuid=hostname\` is configured.
From the Keylime paper \[3\] (section 3.2.2) it sounds like the UUID HMAC
check is not considered a security feature but only a sanity check:

> This provides the node with a quick check to determine if Kb is correct.

When \`extract\_payload\_script=true\` (default) and
\`payload\_script=autorun.sh\` (default) are configured in \`keylime.conf\`
then the provided payload will be unzipped and a potentially contained
\`autorun.sh\` script is executed with full root privileges. Attached you
can find a reproducer script \`post\_key.py\` that demonstrates the issue
by creating a file \`/tmp/evil\` on the Agent host by only providing the
Agent hostname and UUID as input parameters.

Even if \`payload\_script\` is disabled then the extraction of a ZIP file
as \_root\_ might result in a remote root exploit by extracting files
outside of the intended target directory. I did not test this variant of
the attack vector, though. Furthermore by providing a ZIP bomb as
payload the Agent process can be subjected to a remote DoS through
memory exhaustion.

Retrieving the full symmetric key previously stored in
\`/var/lib/keylime/secure/derived\_tci\_key\` should not be possible this
way, because when performing the bootstrap protocol, the previous data
is removed in \`keylime\_agent.py:242\`. A skillful attacker might attempt
to first compromise the Agent node and then wait for the Tenant to
re-deploy the Agent using authentic keys and payload. Should this
succeed then the attacker can obtain the secret symmetric key from the
compromised Agent node after all.

Similar to issue b) I recommend to somehow authenticate and
cryptographically secure this Agent interface to prevent these attacks.
As a hotfix disabling the relevant configuration features should at
least prevent the remote code execution and memory exhaustion attack
vectors. Setting non-predictable UUID values can also help (but one
should also consider item 3.a in this context).  Even then this
interface still allows to disrupt the operational state of the Agent
host by simply overwriting its current configuration.

### Upstream Security Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-2m39-75g9-ff5r

### Upstream Fixes

The fix consists of a larger number of upstream commits regarding
introduction of "mTLS" for the Agent interface. This means the
connection towards the Agent will in the future be cryptographically
secured and thus only trusted actors can use the Agent interface.

The upgrade path is a bit complicated because of this (see upstream
advisory).  Upstream version 6.3.X will introduce the new mTLS support
but not enforce it, to allow upgrading of all Keylime components on all
nodes. Only upstream version 6.4.x will enforce the new protocol.

d) Key Exchange and Bootstrap Protocol Susceptible to Replay Attacks
--------------------------------------------------------------------

Authentic payloads being passed from the Tenant to the Agent should be
reasonably safe from attackers (when not considering issue c)), since
the two halves of the symmetric key are encrypted using the per-agent
node RSA public key. The bootstrap protocol seems to be susceptible to
certain replay attacks, however. Since the interface does not employ
transport security, the bootstrap protocol can simply be recorded and
replayed to activate an authentic configuration payload. This could e.g.
be used by an attacker to activate an outdated or even insecure older
configuration of the Agent node.

### Upstream Fixes

This issue did not receive a dedicated CVE and fix. It is covered
together with the previous issue 2.c).

3) Findings in the Registrar Component
======================================

a) UUID of Agents is Received on Unprotected HTTP Interface
-----------------------------------------------------------

The Registrar provides two separate HTTP interfaces, a TLS protected one
and an unprotected one. Part of the unprotected interface is the Agent
registration.  As part of the Agent registration the Agent UUID is
passed unencrypted (processed in \`registrar\_common.py:229\`).

This is not a security issue in its own but relates to issue 2.c where
the knowledge of the UUID facilitates remote code execution on the Agent
nodes.  This means if an attacker can listen in on the Registrar's Agent
registration communication then even unpredictable Agent UUIDs no longer
hinder the attack described in issue 2.c).

As outlined in 2.c) the UUID does not seem to have been thought of as a
security property in the first place so I see no urge to change anything
here. Although when the bootstrap protocol should get TLS protection
then for completeness it could also make sense to protect this Registrar
interface as well the same way.

### Upstream Fixes

This specific aspect is covered by the following commit:

https://github.com/keylime/keylime/commit/e5f033c66403a899685b81a3af03cd59f76e455f

There is no dedicated CVE but it is covered together with the
overarching introduction of mTLS as outlined in issue 2.c).

b) Unsanitized UUID passed on Unprotected HTTP Interface Facilitates Log Spoofing (CVE-2022-23949)
--------------------------------------------------------------------------------------------------

Since the Registrar's unprotected HTTP interface requires no
authentication, anybody can post arbitrary Agent registrations with
arbitrary parameters. The Agent ID (UUID) parameter is not sanitized in
any way and is used unfiltered in log messages (e.g.
\`registrar\_common.py:107\`).

As a result the Agent ID parameter can be used to inject seemingly valid
additional log lines that appear e.g. in \`journalctl -u
keylime\_registrar.service\`. The attached reproducer script
\`post\_agent.py\` can be used to demonstrate this:

    $ ./post\_agent.py --host registrar-host --log-line "Please run rm -rf /\* to protect your system"

In the journal we will then see:

    Dec 21 11:44:22 registrar-host keylime\_registrar\[1426\]: 2021-12-21 11:44:22.281 - keylime.registrar - WARNING - 
POST for trusted-agent
    Dec 21 11:44:22 registrar-host keylime\_registrar\[1426\]: 2021-12-21 11:44:22.931 - keylime.registrar - WARNING - 
Please run rm -rf /\* to protect your system
    Dec 21 11:44:22 registrar-host keylime\_registrar\[1426\]: 2021-12-21 11:44:22.940 - keylime.registrar - DEBUG - 
returning 400 response. \[...\]

Such log spoofing could be used to entice Administrators to perform
actions that can be harmful or otherwise in the interest of an attacker.

My recommendation is on the one hand to diligently sanitize untrusted
input parameters. On the other hand it might make sense to authenticate
this currently untrusted interface.

### Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-87gh-qc28-j9mm

### Upstream Fixes

The UUID sanitazion is introduced via these commits:

https://github.com/keylime/keylime/commit/387e320dc22c89f4f47c68cb37eb9eec2137f34b
https://github.com/keylime/keylime/commit/e429e95329fc60608713ddfb82f4a92ee3b3d2d9
https://github.com/keylime/keylime/commit/65c2b737129b5837f4a03660aeb1191ced275a57

Otherwise the introduction of mTLS as outlined in issues 3.a) and 2.c)
further protect this.

4) Findings in the Verifier Component
=====================================

a) Revocation Notifier Uses Fixed /tmp Path for UNIX Domain Socket (CVE-2022-23950)
-----------------------------------------------------------------------------------

In \*revocation\_notifier.py\* a fixed path in the world writable location
\*/tmp/keylime.verifier.ipc\* is used. The code (in this case the third
party \`zeromq\` Python module) forcefully removes any file object found
there earlier.  Should the program be running as non-root, or if another
local user simply places a \*directory\* at this location, then this
serves as a local DoS attack against the revocation notifier process,
because the socket cannot be created.

This situation doesn't even seem to be noticed by the Verifier main
process, because the child process \`broker\_proc\` is never waited on.
This means that the local attacker could even replace the "blocking"
directory by his own UNIX domain socket later on and will then receive
revocation events from invocations of the \`notify()\` function in the
main Verifier process.  The full impact of this would have to be
researched further. It looks like failed quote notifications would
longer be sent out.

I recommend to place UNIX domains sockets in a dedicated safe directory
in /run that cannot be staged with attacks by other local users in the
system.

### Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-9r9r-f8xc-m875

### Upstream Fixes

This fix places the socket into a private /run/keylime directory:

https://github.com/keylime/keylime/commit/ea5d0373fa2c050d5d95404eb779be7e8327b911

b) Get Quote Response Contains Possibly Untrusted ZIP Data (CVE-2022-23951)
---------------------------------------------------------------------------

The Verifier process periodically performs quote operations on
registered Agents. As part of this \`process\_quote\_response()\` is called
and furthermore \`check\_quote()\` and finally \`\_tpm2\_checkquote()\`. In
\`tpm\_main.py:1018\` a couple of ZIP data streams are uncompressed via
\`zlib.decompress()\`.

Since this is processing possibly untrusted data - the Verifier is
attempting to verify the current trust status of the node after all - it
needs to be assumed that malicous data can also be supplied here.

Therefore the question arises whether \`zlib.decompress()\` is robust
against processing invalid ZIP data streams. One thing I already found
out is that it is not robust against delivering ZIP bombs that will
cause a memory exhaustion in the Verifier process.

This finding also is valid similarly for all other Keylime interface
that process ZIP data, like in the Agent.

### Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-6xx7-m45w-76m2

### Upstream Fixes

This fix simply removes the ZIP compression from the Verifier interface:

https://github.com/keylime/keylime/commit/6e44758b64b0ee13564fc46e807f4ba98091c355

5) General Findings
===================

This section contains findings that apply to all keylime components
alike.

a) World-Readable keylime.conf Contains Potentially Sensitive Data (CVE-2022-23952)
-----------------------------------------------------------------------------------

The configuration \`/etc/keylime.conf\` is installed world-readable:

    $ ls -l /etc/keylime.conf
    -rw-r--r-- 1 root root 26770 Dec 16 14:54 /etc/keylime.conf

This is the case for installations performed manually via the provided
\`installer.sh\` script as well as for the RPM packaging found in both
openSUSE Tumbleweed and Fedora 35 Linux distributions. Further
distributions might be affected.

\`keylime.conf\` contains a lot of information, some of it sensitive like
the TPM ownership password (\`tpm\_ownerpassword\`), TLS certificate
private key passwords (\`private\_key\_pw\`, \`registrar\_private\_key\_pw\`) or
the database password for the Registrar (\`database\_password\`). Thus this
is a local information leak, because arbitrary local users can obtain
these passwords from the configuration file.

My recommendation is to make this file only accessible to \_root\_ and
adjust all installation routines and possibly documentation. The Keylime
code could perform a sanity check of the permissions of the
configuration file before reading it in.

### Upstream Advisory

https://github.com/keylime/keylime/security/advisories/GHSA-fchm-5w2v-qfm8

### Upstream Fixes

The following fix explicitly sets the permissions for the configuration
file in the installer:

https://github.com/keylime/keylime/commit/883085d6a4bcea3012729014d5b8e15ecd65fc7c

b) Lack of Privilege Separation
-------------------------------

All keylime services are currently designed to run as root all the time
(except for testing purposes, see \`REQUIRE\_ROOT\` in \`config.py\`). Only
few bits of the keylime components actually should need root privileges.
Most notably the bootstrapping scripts in the Agent component or the
ability to bind privileged ports.

Implementing a privilege separation approach would increase the defense
in depth for keylime considerably, avoiding smaller security issues to
become severe fast.

### Upstream Statement

Keylime upstream states that it is already possible to run Keylime as
non-root. The \`REQUIRE\_ROOT\` bits are not strictly necessary any more
and can be removed from the code. The Debian packaging already makes use
of the privilege separation.

6) Timeline
===========

2021-12-09: I started the review on the code
2021-12-23: I contacted the upstream security contact and upstream
            developer Thore Sommer privately by email and provided them
            the report results, offering coordinates disclosure.
2022-01-04: Upstream confirmed most of my findings and work on the fixes
            began. Alberto Planas, a SUSE colleague and maintainer of
            the SUSE Keylime packaging also contributed some fixes.
2022-01-28: Publication of the security advisories and fixes by upstream
            took place. Upstream also discovered some further security
            issues themselves in the meanwhile.

\[1\]: https://github.com/keylime/keylime
\[2\]: https://www.openwall.com/lists/oss-security/2020/06/04/5
\[3\]: https://www.ll.mit.edu/sites/default/files/publication/doc/2018-04/2016\_12\_07\_SchearN\_ACSAC\_FP.pdf

Cheers

Matthias

-- 
Matthias Gerstner <matthias.gerstner () suse de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
 
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev

**Attachment: post\_agent.py**  
_Description:_

**Attachment: post\_key.py**  
_Description:_

**Attachment: signature.asc**  
_Description:_

**Current thread:**

*   **keylime: Multiple Security Issues (including remote code execution in the Agent component)** _Matthias Gerstner (Jan 28)_

CVE-2022-23952: Multiple Security Issues (including remote code execution in the Agent component)

As ransomware attacks continue to evolve, beyond using security best practices organizations can build resiliency with extended detection and response solutions and fast response times to shut down attacks.

Ransomware is the most significant cybersecurity threat facing organizations today. But recently, leaders from the National Security Agency and the FBI both indicated that attacks declined during the first half of 2022. The combination of sanctions on Russia, where many cybercriminal gangs originate, and crashing cryptocurrency markets may have had an effect, making it difficult for ransomware gangs to extract funds and get their payouts.

But we aren't out of the woods yet. Despite a temporary dip, ransomware is not only thriving but also evolving. Today, ransomware-as-a-service (RaaS) has evolved from a commoditized, automated model relying on prepackaged exploit kits, to a human-operated, highly targeted, and sophisticated business operation. That's reason for businesses of any size to be concerned.

**Becoming RaaS**

It is widely known that today's cybercriminals are well equipped, highly motivated, and very effective. They didn't get that way by accident, and they haven't remained so effective without continuously evolving their technologies and methodologies. The motivation of massive financial gain has been the only constant.

Early ransomware attacks were simple, technology-driven attacks. The attacks drove increased focus on backup and restore capabilities, which led adversaries to seek out online backups and encrypt those, too, during an attack. Attacker success led to larger ransoms, and the larger ransom demands made it less likely that the victim would pay, and more likely that law enforcement would get involved. Ransomware gangs responded with extortion. They transitioned to not only encrypting data, but exfiltration and threatening to make public the often-sensitive data of the victim's customers or partners, introducing a more complex risk of brand and reputational damage. Today, it isn't unusual for ransomware attackers to seek out a victim's cyber-insurance policy to help set the ransom demand and make the whole process (including payment) as efficient as possible.

We have also seen less disciplined (but equally damaging) ransomware attacks. For example, choosing to pay a ransom in turn also identifies a victim as a reliable fit for a future attack, increasing the likelihood it will be hit again, by the same or a different ransomware gang. Research estimates between 50% to 80% (PDF) of organizations that paid a ransom suffered a repeat attack.

As ransomware attacks have evolved, so have security technologies, especially in areas of threat identification and blocking. Anti-phishing, spam filters, antivirus, and malware-detection technologies have all been fine-tuned to address modern threats to minimize the threat of a compromise through email, malicious websites, or other popular attack vectors.

This proverbial "cat and mouse" game between adversaries and security providers that deliver better defenses and sophisticated approaches to stopping ransomware attacks has led to more collaboration within global cybercriminal rings. Much like safecrackers and alarm specialists used in traditional robberies, experts in malware development, network access, and exploitation are powering today's attacks and created conditions for the next evolution in ransomware.

**The RaaS Model Today**

RaaS has evolved to become a sophisticated, human-led operation with a complex, profit sharing business model. A RaaS operator who may have worked independently in the past now contracts with specialists to increase chances of a success.

A RaaS operator — who maintains specific ransomware tools, communicates with the victim, and secures payments — will now often work alongside a high-level hacker, who will perform the intrusion itself. Having an interactive attacker inside the target environment enables live decision-making during the attack. Working together, they identify specific weaknesses within the network, escalate privileges, and encrypt the most sensitive data to ensure payouts. In addition, they carry out reconnaissance to find and delete online backups and disable security tooling. The contracted hacker will often work alongside an access broker, who is responsible for providing access to the network through stolen credentials or persistence mechanisms that are already in place.

The attacks resulting from this collaboration of expertise have the feel and appearance of "old-fashioned," state-sponsored advanced persistent threat-style attacks, but are much more prevalent.

**How Organizations Can Defend Themselves**

The new, human operated RaaS model is much more sophisticated, targeted, and destructive than the RaaS models of the past, but there are still best practices organizations can follow to defend themselves.

Organizations must be disciplined about their security hygiene. IT is always changing, and any time a new endpoint is added, or a system is updated, it has the potential to introduce a new vulnerability or risk. Security teams must remain focused on security best practices: patching, using multifactor authentication, enforcing strong credentials, scanning the Dark Web for compromised credentials, training employees on how to spot phishing attempts, and more. These best practices help reduce the attack surface and minimize the risk that an access broker will be able to exploit a vulnerability to gain entry. Additionally, the stronger security hygiene an organization has, the less "noise" there will be for analysts to sort through in the security operations center (SOC), enabling them to focus on the real threat when one is identified.

Beyond security best practices, organizations must also ensure they have advanced threat detection and response capabilities. Because access brokers spend time performing reconnaissance in the organization's infrastructure, security analysts have an opportunity to spot them and stop the attack in its early stages — but only if they have the right tools. Organizations should look to extended detection and response solutions that can detect and cross-correlate telemetry from security events across their endpoints, networks, servers, email and cloud systems, and applications. They also need the ability to respond wherever the attack is identified to shut it down quickly. Large enterprises may have these capabilities built into their SOC, whereas midsize organizations may want to consider the managed detection and response model for 24/7 threat monitoring and response.

Despite the recent decline in ransomware attacks, security professionals shouldn't expect the threat to go extinct anytime soon. RaaS will continue to evolve, with the latest adaptations replaced by new approaches in response to cybersecurity innovations. But with a focus on security best practices paired with key threat prevention, detection, and response technologies, organizations will become more resilient against attacks.

Ransomware: The Latest Chapter

Ubuntu Security Notice 5618-1 - It was discovered the Ghostscript incorrectly handled memory when processing certain inputs. By tricking a user into opening a specially crafted PDF file, an attacker could cause the program to crash.

    ==========================================================================Ubuntu Security Notice USN-5618-1September 20, 2022ghostscript vulnerability==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 16.04 ESMSummary:Ghostscript could be made to crash if it opened a specially crafted.Software Description:- ghostscript: PostScript and PDF interpreterDetails:It was discovered the Ghostscript incorrectly handled memory whenprocessing certain inputs. By tricking a user into opening a speciallycrafted PDF file, an attacker could cause the program to crash.Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 16.04 ESM:   ghostscript                      9.26~dfsg+0-0ubuntu0.16.04.14+esm4   ghostscript-x                   9.26~dfsg+0-0ubuntu0.16.04.14+esm4   libgs9                              9.26~dfsg+0-0ubuntu0.16.04.14+esm4In general, a standard system update will make all the necessary changes.References:   https://ubuntu.com/security/notices/USN-5618-1   CVE-2020-27792

Ubuntu Security Notice USN-5618-1

XPDF 4.04 is vulnerable to Null Pointer Dereference in FoFiType1C.cc:2393.

Post Reply

*   Print view

Advanced search

3 posts • Page **1** of **1**

cyth

**Posts:** 2

**Joined:** Sat Aug 20, 2022 9:49 am

**null pointer dereference caused by no-check malloc pointer**

*   Quote

Post by **cyth** » Sat Aug 20, 2022 10:03 am

Hello.  
I find a npd bug in xpdf 4.04 in FoFiType1C.cc:2393, it may caused by WebFont.cc:198 ( a no-check pointer).  
It can be triggered by a crafted file in attachment by using pdftohtml.

Attachments

npd\_poc.zip

(11.43 KiB) Downloaded 12 times

Top

derekn

**Posts:** 797

**Joined:** Wed Apr 05, 2017 6:57 pm

**Re: null pointer dereference caused by no-check malloc pointer**

*   Quote

Post by **derekn** » Tue Aug 23, 2022 6:49 pm

I'll have that fixed in the next release.

Thanks for the bug report.

Top

cyth

**Posts:** 2

**Joined:** Sat Aug 20, 2022 9:49 am

**Re: null pointer dereference caused by no-check malloc pointer**

*   Quote

Post by **cyth** » Thu Aug 25, 2022 2:53 am

Thanks for your confirmation.

Top

Post Reply

*   Print view

Display: Sort by: Direction:

3 posts • Page **1** of **1**

Return to “Xpdf open source”

Jump to

*   XpdfReader
*   Xpdf open source

CVE-2022-38928: null pointer dereference caused by no-check malloc pointer

A stacked combination of hardware and software protects the next version of Windows against the latest generation of firmware threats.

Microsoft on Tuesday released a hefty PDF detailing Windows 11's new security-focused features, with a heavy emphasis on supporting zero trust.

For a couple of years now, Microsoft, Google, and Amazon have been working with the US federal government on improving cybersecurity through zero trust, among other techniques. It's no coincidence that these are the big three cloud service providers, of course; they are best positioned to institute controls to prevent catastrophic cyberattacks.

But Microsoft is also moving security way down the stack to where cloud rivals can't follow: firmware.

**Hardware Security Under Attack**

While network-level security is mandatory, it is not sufficient to protect against attackers who target firmware and other low-level elements of a computer.

Flaws in firmware for CPUs, printers, and other hardware can open a door to a corporate network. Malware like TrickBot, MoonBounce, and LoJax that worms its way into the silicon is difficult to dislodge.

"These new threats call for computing hardware that is secure down to the very core, including hardware chips and processors which store sensitive business information," Microsoft stated in the new report. "With hardware-based protection, we can enable strong mitigation against entire classes of vulnerabilities that are difficult to thwart with software alone." 

Besides the extra strength of the protection, Microsoft touts less slowdown using hardware-based protection versus running it in software.

The foundation of the built-in hardware security is a partnership between hardware root-of-trust and silicon-assisted security.

**Hardware Root-of-Trust**

Hardware root-of-trust is, by definition, "a starting point that is implicitly trusted." In the case of a PC, it's the part that checks BIOS code to ensure it's legitimate before it boots up. And anyone who's had to remove malware from a machine with infected BIOS knows how vital that is.

The new security measures include storing sensitive data such as cryptographic keys and user credentials isolated from the operating system within a separate secure area. Microsoft requires a Trusted Platform Module (TPM) 2.0 chip to be installed on both new and upgraded Windows 11 machines. The company had required TPM 2.0 capabilities on all new Windows 10 machines, but the latest version of Windows won't even run if the PC doesn't have a TPM 2.0 security chip.

"With hardware-based isolation security that begins at the chip, Windows 11 stores sensitive data behind additional barriers separated from the operating system," Microsoft wrote in its new report. "As a result, information including encryption keys and user credentials are protected from unauthorized access and tampering."

To provide TPM 2.0 protection directly on the motherboard, Windows 11 machines include the Microsoft Pluton security processor on the system-on-chip. While Pluton is not brand new – it was previewed back in November 2020 – integrating TPM 2.0 capabilities in this way eliminates one attack vector: the bus interface between the CPU and the TPM chip.

Not all Windows 11 machines will have a Pluton chip, but they will all have a TPM 2.0 chip.

**Silicon-Assisted Security**

The silicon-assisted security measures in Windows 11 start with a secure kernel carved out using virtualization-based security (VBS). 

"The isolated VBS environment protects processes, such as security solutions and credential managers, from other processes running in memory," Microsoft wrote. "Even if malware gains access to the main OS kernel, the hypervisor and virtualization hardware help prevent the malware from executing unauthorized code or accessing platform secrets in the VBS environment."

Hypervisor-protected code integrity (HCVI) uses VBS to check the validity of code within the secure VBS environment instead of in the main Windows kernel. Kernel mode code integrity (KMCI), as that's called, fends off attempts to modify drivers and the like. KMCI verifies that all kernel code is properly signed and has not been altered before it allows it to run. HVCI is supported in all versions of Windows 11 and enabled by default in most editions.

A further measure of protection against such attacks as memory corruption and zero-day exploits is offered by hardware-enforced stack protection. 

"Based on Controlflow Enforcement Technology (CET) from Intel and AMD Shadow Stacks, hardware-enforced stack protection is designed to protect against exploit techniques that try to hijack return addresses on the stack," Microsoft explained. The OS does this by creating a "shadow stack," set apart from other stacks, for return addresses.

To protect against physical incursions where an intruder surreptitiously installs malware from a device, Microsoft's line of Secured-core PCs will only run executables signed by "known and approved authorities," keeping external peripherals from accessing memory without authorization.

Even more firmware protection comes from Windows 11's universal implementation of the Unified Extensible Firmware Interface (UEFI) Secure Boot standard. The TPM stores a boot audit log, the Static Root of Trust for Measurement (SRTM), to check whether any attempts to subvert the boot were made.

UEFI is not unique to Windows machines, of course, but Windows 11 adds Dynamic Root of Trust for Measurement (DRTM) that checks the UEFI boot process for suspicious activity before allowing it to continue. Non-PC devices such as the Surface tablet use Firmware Attack Surface Reduction in place of DRTM.

Silicon-assisted security is part of the Pro, Pro Workstation, Enterprise, Pro Education, and Education versions of Windows 11. The Home editions will have some of these protections but not the full slate. See Microsoft's website for comparisons.

Tag

#pdf