Kategorie
Akira Ransomware Gang Extorts $42 Million; Now Targets Linux Servers
Linux Kernel 'Make-Me-Root' Flaw Threatens Popular Distros [Updated]
Hackers Target Middle East Governments with Evasive "CR4T" Backdoor
Hackers Target Middle East Governments with Evasive "CR4T" Backdoor
Linus Torvalds Addresses Malicious Developers, Hardware Errors and More at Open Source Summit
Zoom offers AI-based updates to its Workplace collaboration space
Online meeting platform Zoom this week announced updates to its meeting collaboration space Workplace, adding AI-powered capabilities that include a previously released “assistant” that offers post-meeting summaries and the ability to compose chats and email drafts.
Available through Zoom’s desktop app, the Workplace collaboration platform includes the use of its Zoom AI Companion, which it released last September.
The AI Companion, enabled in the toolbar, uses OpenAI’s ChatGPT generative AI (genAI) features to perform tasks such as presenting a summary of a meeting, identifying action items, and prompting users to share next steps with key meeting members.
The company’s new Zoom Phone capabilities also offer post-call summaries, voice mail prioritization, and task extraction, among other features.
In January, Zoom launched a mixed reality app that works with Apple’s Vision Pro headset to offer users a 3D representation of meeting participants along with three dimensional representations of media and design files. For example, an animator or game designer could collaborate and share the latest character model via Zoom’s 3D object sharing capabilities.
Zoom’s Workplace collaboration app offers features such as a combined meetings and calendar view on one tab, along with a new “agenda” view for meeting participants.
Users of Zoom’s desktop app will notice the Workplace name throughout the app, the company said.
Workplace now offers what the company referred to as a “simplified navigation bar” at the top to make it easier for users to organize and find the tabs used most often. Users also can drag and drop tabs into their preferred order.
Workplace also offers a choice of new color themes and to opt for Zoom’s classic dark or light themes in a desktop’s app settings. The toolbar can also be customized by dragging and dropping items (including from the “More” menu) into place.
Finally, Workplace offers a multi-speaker view that will highlight people who are actively speaking in a meeting with more than five participants.
Another feature Zoom said will be available “soon” is the Ask AI Companion, a chatbot that will complete routine user tasks, such as creating meeting preparation materials with relevant content such as meeting summaries and chat threads, drafting agendas, and brainstorming ideas.
“Ask AI Companion will be available throughout Zoom Workplace, so your AI-powered digital assistant is always at your fingertips, helping to elevate your performance and free up your schedule,” Zoom said in a blog post.
Collaboration Software, Generative AI, Productivity Software, Zoom Video CommunicationsReport: Microsoft-OpenAI ownership might get conditional OK from EU regulators
Microsoft’s $13 billion investment in OpenAI might not trigger EU antitrust restrictions since it is unlikely to be viewed as an “acquisition” in the legal sense in that jurisdiction.
A report Wednesday by Reuters said this means Microsoft would likely avoid more formal investigation procedures and potential regulatory stumbling blocks as a result of its investment in the generative AI LLM provider.
Reached for comment, a European Commission spokesperson said that for a transaction to be “notifiable” to EC as a merger, it has to represent a change in control of the affected company “on a lasting basis.”
The spokesperson did not rule out a more formal and rigorous regulatory approach and said its investigation into the Microsoft-OpenAI deal is ongoing.
“While this transaction has not been formally notified, the Commission has been following very closely the situation of control over OpenAI already before the recent events involving its management, including Microsoft’s role on the OpenAI board and the investment agreements between Microsoft and OpenAI,” the spokesperson said.
The EC has yet to conclude, however, that the relationship between the two companies rises to the level of a “change of control” as a result of Microsoft’s investments.
Reuters’ report on the matter notes that UK and US antitrust regulators are also still in the preliminary stages of approval for the deal, with both the UK’s Competition and Markets Authority and the US Department of Justice and FTC thought to be considering their next steps in terms of formal reviews and probes.
Under EU law, a “concentration,” which would be subject to antitrust review, can take place when the change of control in one company is accomplished. This, according to the Consolidated Jurisdictional Notice, can be done by acquiring “sole control” of a company, in the sense of the controlling entity being able to exercise decisive influence over the other.
Sole control can also, however, be found to exist on a purely legal or factual basis, reflecting the myriad of board, stockholder and voting rights arrangements available to corporations doing business in the EU. A majority of voting rights, for example, could provide effective sole control, while a minority shareholder who is likely to succeed in achieving majorities at shareholders’ meetings could be found to be in de facto control.
UK and EU regulators had warned Microsoft in January that its investments in OpenAI could be subject to review despite the company’s insistence that its position on the board is non-voting and therefore that it had no ownership of OpenAI.
Microsoft declined to comment.
Generative AI, Government, Microsoft, RegulationApple wants to improve the carbon offset market
Apple has published its annual environmental report detailing its progress towards becoming completely carbon neutral by 2030. While critics will, of course, condemn the report as “greenwash,” it’s hard to identity many other big firms working quite as hard to be so transparent across the impact of their business.
In the report’s introduction, Lisa Jackson, Apple’s vice president for environment, policy, and social initiatives, confirms that Apple is working in multiple directions to achieve its 2030 target.
“The proof of Apple’s commitment to climate action is in our progress: We’ve slashed emissions by more than half, all while serving more users than ever before,” said Jackson. “More hard work is ahead of us, and we’re focused on harnessing the power of innovation and collaboration to maximize our impact.”
Energy from sun and windTo get there, the company is making deep investments in wind and solar power, new recycling, and materials process technology, and seeking to build sustainability right inside its product designs. It means climate action is on the agenda at every product design meeting, and means the packaging it uses is constantly being optimized to reduce the cost of freight.
It’s important to understand the scope Apple has in this.
The company is already carbon neutral across its own business operations, But in the last few years, it has been working with a rapidly growing number of its own suppliers to achieve the same goal in product manufacturing. More than 320 Apple suppliers have committed to using renewable energy, the company says, while more than 20% of the materials used in Apple products came from recycled sources. Its recently introduced MacBook Air is made with over 50% recycled material.
Recycling for the rest of usApple seems to agree that climate justice is also social justice.
That’s why it matters that the company wants to use 100% recycled rare earth materials in its products. The iPhone 15 range uses 100% recycled cobalt in smartphone batteries. These valuable materials are often described as “conflict minerals,” because they come from active war zones and are often mined at gunpoint by forced labor — including kids. I suppose that Just as Find My iPhone makes stealing Apple’s phones less attractive, dramatic reductions in demand for such minerals might well make even forced labor less profitable.
Apple wants carbon offset transparencyThe company has lots of reasons to take pride in much of what it has achieved to mitigate the consequences of running its business, but not every process or use can be avoided or reduced. To make up for this, Apple makes big use of carbon credits.
A lot of people don’t have much faith in carbon credits as a route to environmental sustainability, which Apple seems to recognize. Not only does it call its use of these an “interim solution,” but stresses that its priority is to reduce emissions rather than rely on that kind of mitigation.
To me, this means Apple’s reliance on carbon credits is the weakest link in the Apple 2030 story. But the fact the company sees it as an interim solution and its investment of over $200 million in high quality offset projects such as those in Africa’s Chyulu Hills or in Guizhou, China show tangible recognition of this.
Apple also gains some brownie points for transparency on its use of carbon offsets because it has published an extensive white paper explaining its approach in a great deal more depth. This includes some key recommendations to perhaps improve the quality of such projects on an industry-wide basis.
We need standards of trustApple wants more independent transparency of carbon offset projects, calls for more coordination and collaboration around them, and better national and international policies to support rapid scale up of carbon removal.
“We believe that a market gap still exists for a centralized transparent process to review individual carbon projects against agreed-upon standards,” the Apple white paper says. That’s as close as you can get to conceding that many of the carbon credit schemes being run and relied upon by big companies now might not actually be making a difference.
But what is at least somewhat reassuring is Apple’s stated willingness to work to improve the quality of carbon offsets, and the urgency with which it seems to see these goals. “We recognize that the current carbon markets aren’t equipped to deal with the scale and integrity of impact needed to achieve a 1.5℃ pathway and remove tens of billions of tons of carbon by 2050,” the white paper states.
“We intend to work to improve the quality of these markets. We’re also aiming to build a pipeline of projects that meet the highest-quality standards that can scale to meet the growing demand for nature-based removals. And we’ll continue to progress our goal of building much-needed solutions for high-quality engineered carbon removals to complement these efforts.”
‘Our planet is in crisis‘Overall, this year’s Apple environmental report shows a company that has moved far beyond lip service to try to tackle the big challenge all of us share today. “Our planet is in crisis, and without urgent action on climate change, we won’t be able to keep global warming to 1.5℃, and avoid the worst climate change impacts,” Apple said.
Please follow me on Mastodon, or join me in the AppleHolic’s bar & grill and Apple Discussions groups on MeWe.
Apple, Green IT, iOS, Technology Industry, Vendors and ProvidersThe Windows Registry Adventure #2: A brief history of the feature
Posted by Mateusz Jurczyk, Google Project Zero
Before diving into the low-level security aspects of the registry, it is important to understand its role in the operating system and a bit of history behind it. In essence, the registry is a hierarchical database made of named "keys" and "values", used by Windows and applications to store a variety of settings and configuration data. It is represented by a tree structure, in which keys may have one or more sub-keys, and every subkey is associated with exactly one parent key. Furthermore, every key may also contain one or more values, which have a type (integer, string, binary blob etc.) and are used to store actual data in the registry. Every key can be uniquely identified by its name and the names of all of its ascendants separated by the special backslash character ('\'), and starting with the name of one of the top-level keys (HKEY_LOCAL_MACHINE, HKEY_USERS, etc.). For example, a full registry path may look like this: HKEY_CURRENT_USER\Software\Microsoft\Windows. At a high level, this closely resembles the structure of a file system, where the top-level key is equivalent to the root of a mounted disk partition (e.g. C:\), keys are equivalent to directories, and values are equivalent to files. One important distinction, however, is that keys are the only type of securable objects in the registry, and values play a much lesser role in the database than files do in the file system. Furthermore, specific subtrees of the registry are stored on disk in binary files called registry hives, and the hive mount points don't necessarily correspond one-to-one to the top-level keys (e.g. the C:\Windows\system32\config\SOFTWARE hive is mounted under HKEY_LOCAL_MACHINE\Software, a one-level nested key).
Fundamentally, there are only a few basic operations that can be performed in the registry. These operations are summarized in the table below:
Hives
Load hive
Unload hive
Flush hive to disk
Keys
Open key
Create key
Delete key
Rename key
Set/query key security
Set/query key flags
Enumerate subkeys
Notify on key change
Query key path
Query number of open subkeys
Close key handle
Values
Set value
Delete value
Enumerate values
Query value data
Before we dive into any of them in particular, let's first trace the registry's evolution and the path that led to its current state.
Windows 3.1The registry was first introduced in Windows 3.1 released in 1992. It was designed as a centralized configuration store meant to address the many shortcomings of basic text configuration files from MS-DOS (e.g. config.sys) and the slightly more structured .INI files from very early versions of Windows. But the first registry was nothing like we know it today: there was only one top-level key (an equivalent of HKEY_CLASSES_ROOT) and only one hive (C:\windows\reg.dat) limited to 64 KB in size, formatted in a custom binary format represented by the magic bytes "SHCC3.10". There were no values (data was assigned directly to keys), and the registry was used solely for OLE/COM and file type registration. This is what the first Regedit.exe looked like when launched in advanced mode:
The first Registry Editor running on Windows 3.1
Despite its limitations, the Windows 3.1 registry was an important milestone, as it established long-lasting concepts like its hierarchical structure and paved the way for today's advanced registry features.
Windows NT 3.1, 3.5 and 3.51One year later in 1993, a new version of Windows was released based on a completely refreshed and more robust kernel design: Windows NT 3.1. To this day, the original NT kernel continues to be the underpinning of all modern versions of Windows up to and including Windows 11 – and the same can be said for its registry implementation. The biggest functional registry changes found in Windows NT 3.x as compared to Windows 3.1 were:
- Introducing many new top-level keys (HKLM, HKCU, HKU) and thus extending the scope of information intended to be stored in the registry.
- Replacing the single reg.dat hive file with a number of separate hives (default, sam, security, software, system located in C:\winnt\system32\config).
- Introducing named values with several possible data types.
- Making registry keys securable.
- Eliminating the 64 KB registry hive limit.
To accommodate these new features, Windows adopted a novel binary format called "regf", which was specifically designed to support the expanded functionality. The core principles behind the format remained unchanged across the NT 3.x version line, but it continued to internally evolve, as signified by the increasing version numbers encoded in the hive file headers. Specifically, pre-release builds of Windows NT 3.1 used regf v1.0, Windows NT 3.1 RTM used regf v1.1, and Windows NT 3.5 and 3.51 used regf v1.2.
Lastly, while Regedit.exe remained the simplistic "Registration Info Editor", a new utility, RegEdt32.exe, was added with far more options and unrestricted access to the system registry. Despite its dated appearance, the structure of the UI began to resemble the shape of the modern registry and the core concepts behind today's registry editor:
RegEdt32.exe running on Windows NT 3.1
Notably, Windows NT 3.1 was the first system whose parts of code are still used today in Windows 11. Based on this observation, we can now confidently claim that the registry code base is over 30 years old.
Windows 95Not long after, in the summer of 1995, Windows 95 was officially released to the public. It quickly became a huge hit, mostly thanks to innovations in the user interface – it was the first version to feature a taskbar, the Start menu, and the general look and feel that we now associate with Windows. With regards to the registry internals, though, it wasn't particularly interesting. It continued the trend started by Windows NT 3.x of expanding the registry into an even more central part of the operating system, and borrowed many of the same high-level concepts. However, since it was based on a completely different kernel than NT, the underlying registry implementation differed, too. All of the registry data was typically stored in just two files: C:\WINDOWS\System.dat and C:\WINDOWS\User.dat. They were encoded in yet another binary format indicated by the "CREG" signature, which was more capable than the Win3.1 format, but inferior to WinNT's regf (e.g. it didn't support security descriptors). The same format was later inherited by subsequent systems from the 9x series, namely Windows 98 and Me, but its legacy ended there. According to my knowledge, the CREG format had minimal impact on the registry's development in the NT line, so a deeper discussion of its internals isn't necessary.
Arguably, the one thing that had the most lasting impact in Windows 95 related to registry was the complete redesign of Regedit.exe, both functionally and visually. It gained the ability to browse the entire registry tree, read existing values and create new ones, rename keys, and search for text strings within keys, values and data. At first glance, it looks almost identical to the modern Registry Editor, with the exception of a few missing options, such as loading custom hives or managing key security. Even the program icon has remained largely unchanged and to many power users, it is synonymous with the Windows registry up to this day:
Redesigned Regedit.exe running on Windows 95
Windows NT 4.0The debut of Windows NT 4.0 in 1996 marked another important milestone for the registry, but this time mostly on the technical side. In terms of visuals, NT 4.0 adopted the same graphical interface as Windows 95, including the new and improved Regedit.exe. As a result of the Regedit addition, Windows NT 4.0 now included two competing registry editors: Regedit from Windows 95 and RegEdt32 from Windows NT 3.x. They shared some overlapping functionality (e.g. the ability to manually traverse the registry and inspect individual values), but each offered some unique features too: only Regedit was capable of searching for data in values, while only RegEdt32 supported managing the security of registry keys. I suspect that the presence of two different tools must have been confusing for users who wanted to modify the system's internal settings: not only did they have to understand the structure of the registry and how to navigate it, but also know which tool to use for a specific task. Both utilities made their way into Windows 2000, but they were finally merged in Windows XP into a single Regedit.exe program. RegEdt32.exe can still be found on modern versions of Windows in C:\Windows\system32 as a historical artifact, but all it currently does is just launch Regedit.exe and terminate.
As mentioned earlier, the really important changes in NT 4.0 happened under the hood. Between the release of NT 3.51 and NT 4.0, the kernel developers updated some internal aspects of the regf format to simplify it and make it more efficient. Furthermore, a new optimization called "fast leaves" was introduced, which added special four-byte hints to the subkey lists in order to speed up key lookups. These changes were substantial and not backwards-compatible, so the version had to be increased again, leading to regf v1.3. This is noteworthy because 1.3 is the earliest hive type that is considered a modern version and that is still supported by today's Windows 10 and 11, even though newer format versions up to 1.6 exist now too. It means that one can copy a hive file off of a Windows NT 4.0 system, load it in Regedit on Windows 11, examine and modify it, copy it back, and each of these steps will work without issue. What is more, the support is not just there for reading archival hives – in documented API functions such as RegSaveKeyExA, version 1.3 is represented by the REG_STANDARD_FORMAT enum, indicating that it is considered the "standard" even as of today. And indeed, there are some core system hives in Windows 11, such as UsrClass.dat mounted at HKEY_USERS\<SID>_Classes, that are still encoded in the regf v1.3 format. So in that sense, Windows NT 4.0 and 11, despite being released decades apart and representing vastly different technological eras, exhibit a fundamental connection.
Modern timesBased on the fact that both the regf hive format and the graphical interface of Regedit have essentially remained the same between 1996 and 2024, one could assume that the internal registry implementation hasn't changed that much, either. We can try to prove or disprove this hypothesis by performing a little experiment, measuring the volume of registry-related code in each consecutive version of Windows. To ensure a consistent methodology and make the survey security-relevant, we will focus on the kernel-mode part of the Configuration Manager, which largely constitutes a local attack surface. Such an analysis is technically feasible and even relatively easy to achieve, because:
- The entirety of the kernel registry-related code is compiled into a single executable image: ntoskrnl.exe.
- Debug symbols (PDB/DBG files) for the kernels of all NT-family systems were made publicly available by Microsoft, either via the Microsoft Symbol Server, symbol packages downloadable from the Microsoft website, or symbol files bundled with the system installation media.
- The kernel code follows a consistent naming convention, where all function names related to the registry start with either "Hv" (standing for Hive), "Cm" (standing for Configuration Manager) or "Vr" (likely standing for Virtualized Registry), with a few minor exceptions.
- There are some very good reverse-engineering tools available today, which can help us count the number of assembly instructions or even the number of decompiled C-like source code lines corresponding to the registry engine.
In my case, I used IDA Pro with Hex-Rays to decompile the entire kernel of each NT-line system, and then ran a post-processing script to extract the registry related functions. After counting the numbers of lines and plotting them on a diagram, here is what we get:
As we can see, there has been an enormous, steady growth of the code base, starting at around 10,000 lines of code in NT 4.0 and increasing tenfold to around 100,000 lines in Windows 11. It is important to reiterate that this only covers the kernel portions of the registry and ignores code found in user-mode libraries such as advapi32.dll, KernelBase.dll or ntdll.dll. Furthermore, I expect that the decompiled code is more dense than the original source code because it doesn't include any comments or whitespace. Taking all this into account, the total extent of the registry code managed by Microsoft is probably much bigger than the numbers shown above.
Going back to the kernel registry code, its expansion in time has been substantial, both in absolute and relative terms. But if these developments are invisible to the average user, what does all of the new code do? The changes can be divided into three major categories:
- Optimizations: changes making the registry more efficient, e.g. introducing a "hash leaf" subkey index type to make key lookups even faster in regf v1.5, or adding a native system call to rename keys in-place without involving an expensive copy+delete operation on an entire subtree.
- Backwards compatibility: changes meant to make legacy applications run seamlessly on modern systems, e.g. registry virtualization.
- New features: changes adding new functionality to the registry or adapting it to new use cases. These are either made available via a new API (thus mainly relevant to software developers), or not documented at all and only used by Windows internally. Examples include support for values larger than 1 MB, registry callbacks, support for transactions, application hives, and differencing hives.
Interestingly, the biggest changes weren't occurring with any regularity, but rather were concentrated in just four versions of Windows: NT 3.1–4.0, XP, Vista and 10 Anniversary Update (1607). This is illustrated in the timeline below:
This is of course not an exhaustive list: it includes the features that I have found to be the most interesting during the security audit, but it is missing modifications related to incremental logging, improvements to how hive files are managed and mapped in memory, and many other optimizations, stability improvements and refactorings implemented by Microsoft throughout the years. But it goes to show that the registry is a highly complex part of the Windows kernel, and one with a lot of potential for deep, interesting bugs just waiting to be discovered.
In the next post, I will share a number of useful sources of information I have discovered while researching the registry. Some of them may be more obvious than others, but all of them have significantly helped me understand certain aspects of the technology or given me the necessary context that I was missing. Until next time!
The Windows Registry Adventure #1: Introduction and research results
Posted by Mateusz Jurczyk, Google Project Zero
In the 20-month period between May 2022 and December 2023, I thoroughly audited the Windows Registry in search of local privilege escalation bugs. It all started unexpectedly: I was in the process of developing a coverage-based Windows kernel fuzzer based on the Bochs x86 emulator (one of my favorite tools for security research: see Bochspwn, Bochspwn Reloaded, and my earlier font fuzzing infrastructure), and needed some binary formats to test it on. My first pick were PE files: they are very popular in the Windows environment, which makes it easy to create an initial corpus of input samples, and a basic fuzzing harness is equally easy to develop with just a single GetFileVersionInfoSizeW API call. The test was successful: even though I had previously fuzzed PE files in 2019, the new element of code coverage guidance allowed me to discover a completely new bug: issue #2281.
For my next target, I chose the Windows registry. That's because arbitrary registry hives can be loaded from disk without any special privileges via the RegLoadAppKey API (since Windows Vista). The hives use a binary format and are fully parsed in the kernel, making them a noteworthy local attack surface. Furthermore, I was also somewhat familiar with basic harnessing of the registry, having fuzzed it in 2016 together with James Forshaw. Once again, the code coverage support proved useful, leading to the discovery of issue #2299. But when I started to perform a root cause analysis of the bug, I realized that:
- The hive binary format is not very well suited for trivial bitflipping-style fuzzing, because it is structurally simple, and random mutations are much more likely to render (parts of) the hive unusable than to trigger any interesting memory safety violations.
- On the other hand, the registry has many properties that make it an attractive attack surface for further research, especially for manual review. It is 30+ years old, written in C, running in kernel space but highly accessible from user-mode, and it implements much more complex logic than I had previously imagined.
And that's how the story starts. Instead of further refining the fuzzer, I made a detour to reverse engineer the registry implementation in the Windows kernel (internally known as the Configuration Manager) and learn more about its inner workings. The more I learned, the more hooked I became, and before long, I was all-in on a journey to audit as much of the registry code as possible. This series of blog posts is meant to document what I've learned about the registry, including its basic functionality, advanced features, security properties, typical bug classes, case studies of specific vulnerabilities, and exploitation techniques.
While this blog is one of the first places to announce this effort, I did already give a talk titled "Exploring the Windows Registry as a powerful LPE attack surface" at Microsoft BlueHat Redmond in October 2023 (see slides and video recording). The upcoming blog posts will go into much deeper detail than the presentation, but if you're particularly curious and can't wait to find out more, feel free to check these resources as a starter. 🙂
Research resultsIn the course of the research, I filed 39 bug reports in the Project Zero bug tracker, which have been fixed by Microsoft as 44 CVEs. There are a few reasons for the discrepancy between these numbers:
- Some single reports included information about multiple problems, e.g. issue #2375 was addressed by four CVEs,
- Some groups of reports were fixed with a single patch, e.g. issues #2392 and #2408 as CVE-2023-23420,
- One bug report was closed as WontFix and not addressed in a security bulletin at all (issue #2508).
All of the reports were submitted under the Project Zero 90-day disclosure deadline policy, and Microsoft successfully met the deadline in all cases. The average time from report to fix was 81 days.
Furthermore, between November 2023 and January 2024, I reported 20 issues that had low or unclear security impact, but I believed the vendor should nevertheless be made aware of them. They were sent without a disclosure deadline and weren't put on the PZ tracker; I have since published them on our team's GitHub. Upon assessment, Microsoft decided to fix 6 of them in a security bulletin in March 2024, while the other 14 were closed as WontFix with the option of being addressed in a future version of Windows.
This sums up to a total of 50 CVEs, classified by Microsoft as:
- 39 × Windows Kernel Elevation of Privilege Vulnerability
- 9 × Windows Kernel Information Disclosure Vulnerability
- 1 × Windows Kernel Memory Information Disclosure Vulnerability
- 1 × Windows Kernel Denial of Service Vulnerability
A full summary of the security-serviced bugs is shown below:
GPZ #
CVE
Title
Reported
Fixed
2295
CVE-2022-34707
Windows Kernel use-after-free due to refcount overflow in registry hive security descriptors
2022-May-11
2022-Aug-09
2297
CVE-2022-34708
Windows Kernel invalid read/write due to unchecked Blink cell index in root security descriptor
2022-May-17
2299
CVE-2022-35768
2022-May-20
2318
CVE-2022-37956
Windows Kernel integer overflows in registry subkey lists leading to memory corruption
2022-Jun-22
2022-Sep-13
2330
CVE-2022-37988
2022-Jul-8
2022-Oct-11
2332
CVE-2022-38037
Windows Kernel memory corruption due to type confusion of subkey index leaves in registry hives
2022-Jul-11
2341
CVE-2022-37990
Windows Kernel multiple memory corruption issues when operating on very long registry paths
2022-Aug-3
CVE-2022-38039
CVE-2022-38038
2344
CVE-2022-37991
2022-Aug-5
2359
CVE-2022-44683
Windows Kernel use-after-free due to bad handling of predefined keys in NtNotifyChangeMultipleKeys
2022-Sep-22
2022-Dec-13
2366
CVE-2023-21675
2022-Oct-6
2023-Jan-10
2369
CVE-2023-21747
Windows Kernel use-after-free due to dangling registry link node under paged pool memory pressure
2022-Oct-13
2389
CVE-2023-21748
2022-Nov-30
2375
Windows Kernel multiple issues in the key replication feature of registry virtualization
2022-Oct-25
CVE-2023-21772
CVE-2023-21773
CVE-2023-21774
2378
CVE-2023-21749
Windows Kernel registry SID table poisoning leading to bad locking and other issues
2022-Oct-31
CVE-2023-21776
2379
CVE-2023-21750
2022-Nov-2
2392
CVE-2023-23420
Windows Kernel multiple issues with subkeys of transactionally renamed registry keys
2022-Dec-7
2023-Mar-14
2408
Windows Kernel insufficient validation of new registry key names in transacted NtRenameKey
2023-Jan-13
2394
CVE-2023-23421
Windows Kernel multiple issues in the prepare/commit phase of a transactional registry key rename
2022-Dec-14
CVE-2023-23422
CVE-2023-23423
2410
CVE-2023-28248
2023-Jan-19
2023-Apr-11
2418
CVE-2023-28271
2023-Jan-31
2419
CVE-2023-28272
2023-Feb-2
CVE-2023-28293
2433
CVE-2023-32019
Windows Kernel KTM registry transactions may have non-atomic outcomes
2023-Mar-7
2023-Jun-13
2445
CVE-2023-35356
Windows Kernel arbitrary read by accessing predefined keys through differencing hives
2023-Apr-19
2023-Jul-11
2452
2023-May-10
2446
CVE-2023-35357
Windows Kernel may reference unbacked layered keys through registry virtualization
2023-Apr-20
2447
CVE-2023-35358
Windows Kernel may reference rolled-back transacted keys through differencing hives
2023-Apr-27
2449
CVE-2023-35382
Windows Kernel renaming layered keys doesn't reference count security descriptors, leading to UAF
2023-May-2
2023-Aug-8
2454
CVE-2023-35386
Windows Kernel out-of-bounds reads due to an integer overflow in registry .LOG file parsing
2023-May-15
2456
CVE-2023-38154
2023-May-22
2457
CVE-2023-38139
2023-May-31
2023-Sep-12
2462
CVE-2023-38141
2023-Jun-26
2463
CVE-2023-38140
Windows Kernel paged pool memory disclosure in VrpPostEnumerateKey
2023-Jun-27
2464
CVE-2023-36803
Windows Kernel out-of-bounds reads and paged pool memory disclosure in VrpUpdateKeyInformation
2023-Jun-27
2466
CVE-2023-36576
2023-Jul-7
2023-Oct-10
2479
CVE-2023-36404
2023-Aug-10
2023-Nov-14
2480
CVE-2023-36403
Windows Kernel bad locking in registry virtualization leads to race conditions
2023-Aug-22
2492
CVE-2023-35633
Windows registry predefined keys may lead to confused deputy problems and local privilege escalation
2023-Oct-6
2023-Dec-12
2511
CVE-2024-26182
Windows Kernel subkey list use-after-free due to mishandling of partial success in CmpAddSubKeyEx
2023-Dec-13
2024-Mar-12
None (MSRC-84131)
CVE-2024-26174
2023-Nov-29
None (MSRC-84149)
CVE-2024-26176
Windows Kernel out-of-bounds read when validating symbolic links in CmpCheckValueList
2023-Nov-29
None (MSRC-84046)
CVE-2024-26173
Windows Kernel allows the creation of stable subkeys under volatile keys via registry transactions
2023-Nov-30
None (MSRC-84228)
CVE-2024-26177
2023-Dec-1
None (MSRC-84237)
CVE-2024-26178
Windows Kernel security descriptor linked list confusion in CmpLightWeightPrepareSetSecDescUoW
2023-Dec-1
None (MSRC-84263)
CVE-2024-26181
Windows Kernel registry quota exhaustion may lead to permanent corruption of the SAM database
2023-Dec-11
ExploitabilitySoftware bugs are typically only interesting to either the offensive/defensive sides of the security community if they have practical security implications. Unfortunately, it is impossible to give a blanket statement regarding the exploitability of all registry-related vulnerabilities due to their sheer diversity on a number of levels:
- Affected platforms: Windows 10, Windows 11, various Windows Server versions (32/64-bit)
- Attack targets: the kernel itself, drivers implementing registry callbacks, privileged user-mode applications/services
- Entry points: direct registry operations, hive loading, transaction log recovery
- End results: memory corruption, broken security guarantees, broken API contracts, memory/pointer disclosure, out-of-bounds reads, invalid/controlled cell index accesses
- Root cause of issues: C-specific, logic errors, bad reference counting, locking problems
- Nature of memory corruption: temporal (use-after-free), spatial (buffer overflows)
- Types of corrupted memory: kernel pools, hive data
- Exploitation time: instant, up to several hours
As we can see, there are multiple factors at play that determine how the bugs came to be and what state they leave the system in after being triggered. However, to get a better understanding of the impact of the findings, I have performed a cursory analysis of the exploitability of each bug, trying to classify it as either "easy", "moderate" or "hard" to exploit according to my current knowledge and experience (this is of course highly subjective). The proportions of these exploitability ratings are shown in the chart below:
The ratings were largely based on the following considerations:
- Hive-based memory corruption is generally considered easy to exploit, while pool-based memory corruption is considered moderate/hard depending on the specifics of the bug.
- Triggering OOM-type conditions in the hive space is easy, but completely exhausting the kernel pools is more difficult and intrusive.
- Logic bugs are typically easier and more reliable to exploit than memory corruption.
- The kernel itself is typically easier to attack than other user-mode processes (system services etc.).
- Direct information disclosure (leaking kernel pointers / uninitialized memory via various channels) is usually straightforward to exploit.
- However, random out-of-bounds reads, as well as read access to invalid/controlled cell indexes is generally hard to do anything useful with.
Overall, it seems that more than half of the findings can be feasibly exploited for information disclosure or local privilege escalation (rated easy or moderate). What is more, many of them exhibit registry-specific bug classes which can enable particularly unique exploitation primitives. For example, hive-based memory corruption can be effectively transformed into both a KASLR bypass and a fully reliable arbitrary read/write capability, making it possible to use a single bug to compromise the kernel with a data-only attack. To demonstrate this, I have successfully developed exploits for CVE-2022-34707 and CVE-2023-23420. The outcome of running one of them to elevate privileges to SYSTEM on Windows 11 is shown on the screenshot below:
Upcoming posts in this series will introduce you to the Windows registry as a system mechanism and as an attack surface, and will dive deeper into practical exploitation using hive memory corruption, out-of-bounds cell indexes and other amusing techniques. Stay tuned!
Prevent Generative AI Data Leaks with Chrome Enterprise DLP
Generative AI has emerged as a powerful and popular tool to automate content creation and simple tasks. From customized content creation to source code generation, it can increase both our productivity and creative potential.
Businesses want to leverage the power of LLMs, like Gemini, but many may have security concerns and want more control around how employees make sure of these new tools. For example, companies may want to ensure that various forms of sensitive data, such as Personally Identifiable Information (PII), financial records and internal intellectual property, is not to be shared publicly on Generative AI platforms. Security leaders face the challenge of finding the right balance — enabling employees to leverage AI to boost efficiency, while also safeguarding corporate data.
In this blog post, we'll explore reporting and enforcement policies that enterprise security teams can implement within Chrome Enterprise Premium for data loss prevention (DLP).
1. View login events* to understand usage of Generative AI services within the organization. With Chrome Enterprise's Reporting Connector, security and IT teams can see when a user successfully signs into a specific domain, including Generative AI websites. Security Operations teams can further leverage this telemetry to detect anomalies and threats by streaming the data into Chronicle or other third-party SIEMs at no additional cost.
2. Enable URL Filtering to warn users about sensitive data policies and let them decide whether or not they want to navigate to the URL, or to block users from navigating to certain groups of sites altogether.
For example, with Chrome Enterprise URL Filtering, IT admins can create rules that warn developers not to submit source code to specific Generative AI apps or tools, or block them.
3. Warn, block or monitor sensitive data actions within Generative AI websites with dynamic content-based rules for actions like paste, file uploads/downloads, and print. Chrome Enterprise DLP rules give IT admins granular control over browser activities, such as entering financial information in Gen AI websites. Admins can customize DLP rules to restrict the type and amount of data entered into these websites from managed browsers.
For most organizations, safely leveraging Generative AI requires a certain amount of control. As enterprises work through their policies and processes involving GenAI, Chrome Enterprise Premium empowers them to strike the balance that works best. Hear directly from security leaders at Snap on their use of DLP for Gen AI in this recording here.
Learn more about how Chrome Enterprise can secure businesses just like yours here.
*Available at no additional cost in Chrome Enterprise Core
Slack AI now available to all paid users
Slack’s generative AI (genAI) features are now available to all customers on paid accounts, at a cost of $10 per user each month for those on Slack Pro and Business+ plans.
The collaboration software vendor, owned by Salesforce, brought the genAI features to enterprise customers in February (pricing wasn’t publicly announced). On Thursday, Slack extended access to a wider range of business users on Slack Pro and Business+ plans.
It means all paid customers will get access to the genAI features announced by Slack last year:
- AI-powered search. This provides personalized answers to questions based on an organization’s knowledge base. Slack AI helps users locate subject matter experts, or find information on anything from work projects to understanding unfamiliar acronyms.
- Channel recaps. This highlights key discussion points for a Slack user after a period away from the app, or for those who have recently joined a channel.
- Thread summaries. This feature recaps faster-moving discussions, provides thread summaries, and offers an overview of long conversations, with links to sources in each summary that enable users to check information where necessary.
In addition, Slack has added a “daily digest” that provides users with a recap of what’s been going on in channels they might only visit occasionally.
Slack AI queries are processed using the firm’s large language models (LLMs), which are hosted in its own virtual private cloud running on Amazon Web Service servers, the company said in a blog post Thursday. The company said customer data is not used to train the Slack AI LLM.
Slack is one of many collaboration and productivity software vendors to introduce genAI features in the past year. Some, like Google and Microsoft charge an additional fee for access to these capabilities; others such as Zoom include them for free in paid subscriptions. IDC expects that premiums charged for AI features will contribute to growth in business spending on collaboration apps, which is forecast to reach $71.6 billion in 2027, according to a report by the analyst firm.
Irwin Lazar, president and principal analyst at Metrigy, believes Slack customers will find value in using Slack AI to summarize conversations and improve the ability to search and surface information within chats.
“Our research shows that about 86% of companies are willing to purchase generative AI assistants/copilots for at least some users, though most have not yet determined measurable benefit,” he said.
For companies that use Slack intensively, the $10 a month per user license fee is “a bit easier to swallow”than more expensive genAI products, such as the $30 a month fee for Microsoft 365 Copilot, he said.
Cheaper options for genAI assistants are starting to appear, too. This includes the $20 Copilot Pro from Microsoft, and a recently introduced Google Workplace “add-on” that provides access to genAI features for its Meet video conferencing and Chat messaging apps. This, like Slack AI, costs $10 per user a month, and forgoes access to genAI features in the wider Workspace productivity suite in favor of features targeted specifically at collaboration. (Google also offers $20 and $30 per user/month subscriptions to its Gemini AI assistant.)
The appearance of lower-priced genAI options likely reflects “the need to monetize a service that can be onerous for vendors to provide,” said Raúl Castañón, senior research analyst at 451 Research, part of S&P Global Market Intelligence.
This can be good news for customers, he said. A growing range of payment options means business can opt to provide a full set of genAI features to those employees more likely to use them extensively in their day-to-day work, while providing a cheaper option for a wider user base to accelerate adoption, he said, and avoiding the risk of leaving behind a substantial number of workers.
The proliferation of AI assistants throws up other challenges for customers. In many cases, organizations will use some combination of Microsoft Teams, Google Meet/Chat, and Slack products for productivity and collaboration. This potentially means paying for two or more disconnected AI assistants, should customers wish to access genAI features in multiple products.
“[T]he challenge for organizations in mixed vendor environments, [is that] they must consider paying for multiple generative AI tools, each only having insight into one vendor’s data,” said Lazar. “We’re continuing to look at whether or not vendors will share data, or whether or not generative AI copilots will drive vendor consolidation.”
Slack has other AI features in the works. The company plans to extend its AI search and summarization capabilities to access a wider range of data sources, including Slack apps, canvases, clips, and files uploaded to the collaboration app. This will enable more detailed, contextual responses to queries. Slack’s AI will also be used to create summaries of conversations held in its “huddle” audio and video call tool.
An integration with Salesforce’s Einstein Copilot is also on the way; it will enable Slack users to query the CRM chatbot about sales data from within the Slack app.
Collaboration Software, Generative AI, Productivity Software, SlackOfflRouter Malware Evades Detection in Ukraine for Almost a Decade
OfflRouter Malware Evades Detection in Ukraine for Almost a Decade
FIN7 Cybercrime Group Targeting U.S. Auto Industry with Carbanak Backdoor
FIN7 Cybercrime Group Targeting U.S. Auto Industry with Carbanak Backdoor
Recover from Ransomware in 5 Minutes—We will Teach You How!
Recover from Ransomware in 5 Minutes—We will Teach You How!
New Android Trojan 'SoumniBot' Evades Detection with Clever Tricks
How to Conduct Advanced Static Analysis in a Malware Sandbox
- « první
- ‹ předchozí
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- …
- následující ›
- poslední »