The BGP daemon (bgpd) in IP Infusion ZebOS through 7.10.6 allow remote attackers to cause a denial of service by sending crafted BGP update messages containing a malformed attribute.

**Aug 29 2023**

Border Gateway Protocol is the de facto protocol that directs routing decisions between different ISP networks, and is generally known as the “glue” that holds the internet together. It’s safe to say that the internet we currently know would not function without working BGP implementations.

However, the software on those networks’ routers (I will refer to these as edge devices from now on) that implements BGP has not had a flawless track record. Flaws and problems do exist in commercial and open source implementations of the world’s most critical routing protocol.

Most of these flaws are of course benign in the grand scheme of things; they will be issues around things like route filtering, or insertion, or handling withdraws. However a much more scary issue is a BGP bug that can propagate after causing bad behaviour, akin to a computer worm.

While debugging support for a future feature for my business (bgp.tools) I took a brief diversion to investigate something, and what I came out with might be one of the most concerning things I’ve discovered for the reliability of the internet. To understand the problems, though, we will need a bit more context.

**A mistaken attribute**

On 2 June 2023, a small Brazilian network (re)announced one of their internet routes with a small bit of information called an attribute that was corrupted. The information on this route was for a feature that had not finished standardisation, but was set up in such a way that if an intermediate router did not understand it, then the intermediate router would pass it on unchanged.

As many routers did not understand this attribute, this was no problem for them. They just took the information and propagated it along. However it turned out that Juniper routers running even slightly modern software did understand this attribute, and since the attribute was corrupted the software in its default configuration would respond by raising an error that would shut down the whole BGP session. Since a BGP session is often a critical part of being “connected” to the wider internet, this resulted in the small Brazilian network disrupting other networks’ ability to communicate with the rest of the internet, despite being 1000’s of miles away.

A reader has pointed out that the attribute in question was not actually corrupted, but the support was just unfinished it appears

The packet that causes session shutdowns was really quite benign at first glance:

When a BGP session shuts down due to errors, customer network traffic generally stops flowing down that cable until the BGP connection is automatically restarted (typically within seconds to minutes).

This appears to be what happened to a number of different carriers, for example COLT was heavily impacted by this. Their outage is what originally drew some of my attention to this subject area.

To understand why this sort of thing can happen, we’ll need to take a deeper look at what BGP route attributes are, and what they’re used for.

**What is a BGP Route Attribute?**

At their core a BGP UPDATEs purpose is to tell another router about some traffic that it can (or can no longer) send to it. However just knowing directly what you can send to another router is not very useful without _context_.

For this reason a BGP packet is split up into two sections: the Network Layer Reachability Information (NLRI) data (aka, the IP address ranges), and the attributes that help describe extra context about that reachability data.

Arguably the most used attribute is the AS\_PATH (or actually, the AS4\_PATH), an attribute that tells you which networks a route has travelled through to get to you. Routers use this list of networks to pick paths for their traffic that are either the fastest, economically viable, or least congested, playing a critical role in ensuring that things run smoothly.

At the time of writing there are over 32 different route attribute types, 14 deprecated ones, and 209 officially unassigned ones. The Internet Assigned Numbers Authority (IANA) is in charge of assigning codes to each BGP attribute type codes, normally off the back of IETF Internet-Drafts. The IANA list doesn’t always give the full story, though, as not all internet-drafts make their way into more official documents (like RFC’s), so code numbers are assigned (or sometimes even “squatted”) to attribute types that did not get wide deployment.

**Unknown attribute propagation**

At the start of every route attribute is a set of flags, conveying information about the attribute. One important flag is called the “transitive bit”:

If a BGP implementation does not understand an attribute, and the transitive bit is set, it will copy it to another router. If the router does understand the attribute then it may apply its own policy.

At a glance this “feature” seems like an incredibly bad idea, as it allows possibly unknown information to propagate blindly through systems that do not understand the impact of what they are forwarding. However this feature has also allowed widespread deployment of things like Large Communities to happen faster, and has arguably made deployment of new BGP features possible at all.

**When attribute decoding goes wrong**

What happens when an attribute fails to decode? The answer depends strongly on if the BGP implementation has been updated to use RFC 7606 logic or not; If the session is _not_ RFC 7606 compliant, then typically an error is raised and the session is shut down. If it is, the session can usually continue as normal (except the routes impacted by the decoding error are treated as unreachable).

BGP session shutdowns are particularly undesirable, as they will impact traffic flow along a path. However in the case of a “Transitive” error they can become worm-like. Since not all BGP implementations support the same attributes, an attribute that is unknown to one implementation (and subsequently forwarded along) can cause another implementation to shut down the session it received it from.

With some reasonably educated crafting of a payload, someone could design a BGP UPDATE that “travels” along the internet unharmed, until it reaches a targeted vendor and results in that vendor resetting sessions. If that data comes down the BGP connections that are providing wider internet access for the network, this could result in a network being pulled offline from the internet.

This attack is not even a one-off “hit-and-run”, as the “bad” route is still stored in the peer router; when the session restarts the victim router will reset again the moment the route with the crafted payload is transmitted again. This has the potential to cause prolonged internet or peering outages.

This is a large part of why the RFC mentioned earlier, RFC 7606, exists; looking at its security considerations section, we can see a description of this exact problem::

> Security Considerations This specification addresses the vulnerability of a BGP speaker to a potential attack whereby a distant attacker can generate a malformed optional transitive attribute that is not recognized by intervening routers. Since the intervening routers do not recognize the attribute, they propagate it without checking it. When the malformed attribute arrives at a router that does recognize the given attribute type, that router resets the session over which it arrived. Since significant fan-out can occur between the attacker and the routers that do recognize the attribute type, this attack could potentially be particularly harmful.

In a basic BGP setup this is bad, but with extra engineering it could be used to partition large sections of the internet. If BGP sessions between carriers are forced to reset in this way, causing traffic flow to stop, some routes on the internet would not have alternatives to use, making this a family of bugs that is a grave threat to the overall reliability of the internet.

**Building a basic fuzzer**

**Important Commitment:** I run a business that involves being peered to many IXP route servers and other peoples routers. I have not and will not ever test for BGP bugs/exploits on customer/partner sessions (unless they give consent).

All testing here has been done either on GNS3 VMs, or physical hardware I have hanging around and in isolated VLANs.

To figure out if this would be a practically exploitable attack, I decided to write a fuzzer that would try to stuff random data in random attribute codes to see if I could get sessions to reset on different vendors BGP implementations.

Because I am looking for problems that are “wormable”, I added a Bird 2 router in between my fuzzer and the router being tested. This way Bird will filter out all of the obvious non-exploitable issues, and leave me with the packets that are of concern.

All good fuzzers should be able to run unattended, so how do we teach the fuzzer to tell if the session has reset itself? The solution I came to was that the Victim router would always announce a keepalive prefix, 192.0.2.0/24 (aka TEST-NET-1) and the fuzzer would treat a withdraw of that prefix (from the intermediate bird router) as a sign the session went down, and report back the parameters that caused that to happen!

Testing the fuzzer, I can see that the bird output shows unknown attributes as their type code, and a hex encoding of their contents. In addition it puts a [t] to indicate that it is transitive.

    198.51.100.0/24      unicast [fuzzer 21:31:24.378] * (100) [AS65001?]
    	via 192.168.5.1 on ens5
    	Type: BGP univ
    	BGP.origin: Incomplete
    	BGP.as_path: 65001
    	BGP.next_hop: 192.168.5.1
    	BGP.local_pref: 100
    	BGP.community: (123,2345)
    	BGP.ec [t]: 7d cc c7 30
    

Now that the fuzzer was able to run itself, all that was left was to test all of the vendors one by one…

**Fuzzer findings / Impacted Vendors**

Keep in mind that the described issues are applicable if you are running an edge device with full BGP tables. If you are not running a “full routing table” or a partial peering table, then you are less likely to be impacted by these discoveries.

Another thing to keep in mind, the issues below are different to the ones that the team at Forescout recently presented at BlackHat.

Unimpacted Vendors:

*   MikroTik RouterOS 7+
*   Ubiquiti EdgeOS
*   Arista EOS
*   Huawei NE40
*   Cisco IOS-XE / “Classic” / XR
*   Bird 1.6, All versions of Bird 2.0
*   GoBGP

**Juniper JunOS Impact**

Similar to the problem that caused this research to be done, another exploitable Attribute was found in the form of Attribute 29 (BGP-LS). Due to the nature of the attribute it is unlikely that an exploit attempt will propagate too far over the internet, however peering sessions and route servers are still at risk.

All Juniper users are **urged** to enable bgp-error-tolerance:

    [edit protocols bgp]
    root# show 
    group TRANSIT {
        import import-pol;
        export send-direct;
        peer-as 4200000001;
        local-as 4200000002;
        neighbor 192.0.2.2;
    }
    bgp-error-tolerance;
    

In all tested cases, enabling bgp-error-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

A JunOS software release is expected in the future to correct this. One member of staff at Juniper has also authored an Internet-Draft at the IETF around handling these issues. Juniper is tracking this issue as CVE-2023-4481 / JSA72510.

**Nokia SR-OS Impact**

Fuzzing SR-OS (Version 22.10) revealed many, likely highly propagatable and thus exploitable attributes.

All Nokia SR-OS and SR-Linux users are **urged** to enable error-handling update-fault-tolerance on their devices.

     bgp
         group "TRANSIT"              
             export "yes"
             error-handling
                 update-fault-tolerance
             exit
             neighbor 192.0.2.2
                 peer-as 2
             exit
         exit
         no shutdown
     exit
    

In all tested cases, enabling update-fault-tolerance does not reset sessions, and applies the improved behaviour without restarting sessions.

To the best of my understanding, Nokia has no plans to correct these issues, instead suggesting customers apply error-handling update-fault-tolerance to their BGP groups.

**FRR Impact (and other downstream vendors)**

FRR attempts to handle bad attributes using RFC 7606 behaviour. However the fuzzer discovered that a corrupted attribute 23 (Tunnel Encapsulation) will cause a session to go down regardless.

After reporting this bug to FRR maintainers I received an acknowledgement of the issue and understanding that the issue is a DoS risk to FRR users, but I have not managed to get anything out of FRR since.

This bug is being tracked as CVE-2023-38802 and at the time of writing has no patch or fix.

FRR is packaged inside many other products, to name a few: SONIC, PICA8, Cumulus, and DANOS.

**OpenBSD OpenBGPd Impact**

OpenBGPd also supports the improved RFC 7606 behaviour, however it was found that the recently added Only To Customer implementation could cause session resets. This issue was very rapidly fixed after being reported to them, and is tracked as CVE-2023-38283.

OpenBSD users can install Errata 006 to mitigate this issue.

**Extreme Networks EXOS Impact**

As a result of fuzzing EXOS, the program revealed 2 highly propagatable and thus exploitable attributes in the form of:

*   Attribute 21: AS\_PATHLIMIT
*   Attribute 25: IPv6 Address Specific Extended Community

There is currently no known patch or mitigating config for this issue.

I made Extreme aware of this problem, however after a back and forth with them waiting for what I understood was an implied release of a patch or fix, they communicated that they will not be fixing it in the near future.

A quote from the security email thread (I’ve added emphasis to the critical parts of their response):

> After review of all the material, **we are not considering this a vulnerability due to the presence of RFC 7606**, as well as a history of documentation expressing these concerns all the way back to early 2000s, if not earlier. Malformed attributes are not a novel concept as an attack vector to BGP networks, as evidenced by RFC 7606, which is almost a decade old. As such, customers that have chosen to not require or implement RFC 7606 have done so willingly and with knowledge of what is needed to defend against these types of attacks. Thus, the expectation that we’ll reset our BGP sessions based on RFC 4271 attribute handling is proper. We do abide by other RFCs, in which we claim support, that update RFC 4271. Other vendors do claim RFC 7606 support and have been sharing these controls as a mitigation to malformed attribute response. They don’t appear to be producing new work product to account for these behaviors. **We are evaluating support for RFC 7606 as a future feature.** Obviously, if customers desire a different response, we’ll work through our normal feature request pipelines to address. This is no different than any other RFC support request.

I cannot overstate how much I disagree with Extreme’s response to this, and in the interests of full transparency (and to avoid any allegations of editorialising this, in my view, extremely poor response), I have made the full email exchange available here: (PDF).

**The Vendor Security Response**

I’ve been through my fair share of security issue discoveries, and over time I’ve taken a stronger leaning into “simply do not report” or “full disclosure without warning”, rather than the now commonly accepted 90 day “responsible disclosure” methodology. This is mostly because I’ve had really poor experiences when disclosing issues to security teams.

The bugs discussed in this post cover many vendors and implementations. Full disclosure was originally my plan, however due to the clear risk of harm to the general internet routing system from these findings, I felt it was likely inexcusable to do full-disclosure. (Plus, a malicious deployment of these findings could have a small but I believe very real chance of a “kinetic response” from a misunderstanding.)

Overall the response from vendors has been mostly disappointing. One vendor was extremely hard to find contacts for, and I feel that they were stringing me along for some time, only to reply back that they were not going to fix the problem.

Other vendors notably were not immediately interested in notifying customers of mitigating config to the problems, however when I personally started extending notices to my peers at larger carriers about the problems (since if they were not going to, I was going to try and reduce the exploit surface) a vendor notice was issued.

No vendor that I reported to has any form of bug bounty, and this entire adventure has consumed huge volumes of my time and mental capacity. In a normal situation this “cost” would have simply been eaten by an employer whose interest is name recognition or altruistic actions. However I am self-employed with my own company (that admittedly does have an interest in a functioning BGP ecosystem), and so this entire adventure has simply delayed product development that I (and customers) really would have liked to have done.

With all of that in mind, my “good faith” advice to people reporting security bugs in network vendor software is that contacting vendors is not an effective solution.

The people on the other side are either already overloaded, or generally don’t care about receiving issues. Since there is no motivation to report bugs (either in the form of bug bounties, or being treated well), I see no reason to do responsible disclosure (apart from cases where it would clearly protect their innocent customers from misery, while accounting for the risk of a vendor simply doing nothing).

The two options, as far as I see it, are either being strung along by a vendor over email for 90 days and then likely finding out nothing is done, or full disclosure.

I worry about the state of networking vendors.

With that being said, I would like to thank the OpenBSD security team, who very rapidly acknowledged my report, and prepared a patch. My only regret with dealing with the OpenBSD team was reporting the issue to them too quickly.

**Closing thoughts**

As mentioned before, with a few of the vendors (Nokia, Extreme, Juniper) I found myself contacting their own customers myself to warn them to enable mitigating config, as that proved to be a much more effective way at preventing risk than trying to push the vendor itself into action.

As a result at least several incumbent ISPs, 1 large CDN, and 2 “Tier 1” networks have applied configuration to help prevent these issues from impacting them.

If the goal of reporting security flaws is to reduce harm to their customers, I’m not convinced that reporting problems to vendors has enough of an effective impact to be worth doing, vs the loss of personal time and sanity.

Several people I spoke to have been incredibly helpful (some who could not be listed here). I would like to thank the following people for having some role in helping me either discover/disclose these problems, editing this post, or general support for when vendors were being very frustrating.

*   Basil Fillan
*   Alistair Mackenzie
*   Will Hargrave
*   Filippo Valsorda
*   Joseph Lorenzo Hall
*   Job Snijders
*   eta

If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Mastodon/Fediverse @benjojo@benjojo.co.uk

If you run a network and are interested in BGP monitoring do check out bgp.tools! Otherwise if you like what I do or think that you could do with some of my bizarre areas of knowledge I am also open for contract work, please contact me over at workwith@benjojo.co.uk!

Until next time!

CVE-2023-45886: Grave flaws in BGP Error handling

A WIRED analysis of leaked police documents verifies that a secretive government program is allowing federal, state, and local law enforcement to access phone records of Americans who are not suspected of a crime.

A little-known surveillance program tracks more than a trillion domestic phone records within the United States each year, according to a letter WIRED obtained that was sent by US senator Ron Wyden to the Department of Justice (DOJ) on Sunday, challenging the program’s legality.

According to the letter, a surveillance program now known as Data Analytical Services (DAS) has for more than a decade allowed federal, state, and local law enforcement agencies to mine the details of Americans’ calls, analyzing the phone records of countless people who are not suspected of any crime, including victims. Using a technique known as chain analysis, the program targets not only those in direct phone contact with a criminal suspect but anyone with whom those individuals have been in contact as well.

The DAS program, formerly known as Hemisphere, is run in coordination with the telecom giant AT&T, which captures and conducts analysis of US call records for law enforcement agencies, from local police and sheriffs’ departments to US customs offices and postal inspectors across the country, according to a White House memo reviewed by WIRED. Records show that the White House has, for the past decade, provided more than $6 million to the program, which allows the targeting of the records of any calls that use AT&T’s infrastructure—a maze of routers and switches that crisscross the United States.

In a letter to US attorney general Merrick Garland on Sunday, Wyden wrote that he had “serious concerns about the legality” of the DAS program, adding that “troubling information” he’d received “would justifiably outrage many Americans and other members of Congress.” That information, which Wyden says the DOJ confidentially provided to him, is considered “sensitive but unclassified” by the US government, meaning that while it poses no risk to national security, federal officials, like Wyden, are forbidden from disclosing it to the public, according to the senator’s letter.

AT&T spokesperson Kim Hart Jonson declined WIRED’s request to comment on the DAS program, saying only that the company is required by law to comply with a lawful subpoena.

There is no law requiring AT&T to store decades’ worth of Americans’ call records for law enforcement purposes. Documents reviewed by WIRED show that AT&T officials have attended law enforcement conferences in Texas as recently as 2018 to train police officials on how best to utilize AT&T’s voluntary, albeit revenue-generating, assistance.

In 2020, the transparency collective Distributed Denial of Secrets published hundreds of gigabytes of law enforcement data stolen from agencies around the US. A WIRED review of the files unearths extraordinary detail regarding the processes and justifications that agencies use to monitor the call records of not only criminal suspects, but of their spouses, children, parents, and friends. While DAS is managed under a program devoted to drug trafficking, a leaked file from the Northern California Regional Intelligence Center (NCRIC) shows that local police agencies, such as those in Daly City and Oakland, requested DAS data for unsolved cases seemingly unrelated to drugs.

In one instance, an officer with the Oakland Police Department asked for a “Hemisphere analysis” to identify the phone number of a suspect by analyzing the calls of the suspect’s close friends. In another, a San Jose law enforcement officer asked the Northern California Regional Intelligence Center to identify a victim and material witness in an unspecified case. One officer, soliciting information from AT&T under the program, wrote: “We obtained six months of call data for \[suspect\]'s phone, as well as several close associations (his girlfriend, father, sister, mother).” The records do not indicate how AT&T responds to every request.

Leaked law enforcement files further show that a range of officials—from a US Postal Service inspector to a New York Department of Corrections parole officer—participated in DAS training sessions. Other participants include port authorities and members of US Immigration & Customs Enforcement, National Guard, and California Highway Patrol, alongside scores of smaller agencies.

First disclosed by _The New York Times_ in September 2013 as Hemisphere, the DAS program—renamed in 2013—has since flown largely under the radar. Internal records concerning the program’s secrecy that were obtained by the newspaper at the time show that law enforcement had long been instructed to never “refer to Hemisphere in any official document.”

Following the _Times_’ story, former US president Barack Obama reportedly suspended funding for the Hemisphere program in 2013. And while discretionary funding was withheld over the following three years, a White House memo obtained by WIRED shows that individual law enforcement organizations across the US were permitted to continue contracting with AT&T directly in order to maintain access to its data-mining service. Funding resumed under former president Donald Trump but was halted again in 2021, according to the White House memo. Last year, under president Joe Biden, the funding resumed once more, the memo says.

The White House acknowledged an inquiry from WIRED but has yet to provide a comment.

The DAS program is maintained under an affiliated program called HIDTA, funded by the White House’s Office of National Drug Control Policy (ONDCP). HIDTA, or “high-intensity drug trafficking area,” is a designation assigned to 33 different regions of the US, according to the White House. The first five regions, mapped out in 1990, included areas around Los Angeles, Houston, Miami, New York, and the entire US-Mexico border, some of the nation’s most active drug trafficking areas.

The collection of call record data under DAS is not wiretapping, which on US soil requires a warrant based on probable cause. Call records stored by AT&T do not include recordings of any conversations. Instead, the records include a range of identifying information, such as the caller and recipient’s names, phone numbers, and the dates and times they placed calls, for six months or more at a time. Documents released under public records laws show the DAS program has been used to produce location information on criminal suspects and their known associates, a practice deemed unconstitutional without a warrant in 2018.

“Requests concerning location information require the highest level of legal demand, which is a court-issued warrant, except in emergency situations,” AT&T’s Hart Jonson says.

Orders targeting a nexus of individuals are sometimes called “community of interest” subpoenas, a phrase that among privacy advocates is synonymous with dragnet surveillance.

“The scale of the data available to and routinely searched for the benefit of law enforcement under the Hemisphere Project is stunning in its scope,” Wyden’s letter to Garland says.

The White House has provided at least $6.1 million in discretionary funding to the DAS program since 2013, according to a two-page memo authored last year by White House officials. An internal HIDTA “participant guide” reviewed by WIRED shows that HIDTA funding exceeded $280 million in 2020 alone. It remains unclear how much HIDTA funding is spent to support AT&T’s vast collection of American call records.

It is not currently known how far back the call records accessible under DAS go. A slide deck released under the Freedom of Information Act in 2014 states that up to 10 years’ worth of records can be queried under the program, a statistic that contrasts with other internal documents that claimed AT&T could reach decades into the past. AT&T’s competitors, meanwhile, typically retain call records for no more than two years. (The necessity for phone companies to track call records for extended periods of time has gradually decreased with the disappearance of long-distance charges.)

The DAS program echoes multiple dragnet surveillance programs dating back decades, including a Drug Enforcement Agency program launched in 1992 that forced phone companies to surrender records of virtually all calls going to and from over 100 other countries; the National Security Agency’s bulk metadata collection program, which the US Second Circuit Court of Appeals deemed illegal in 2014; and the Call Details Records program, which suffered from “technical irregularities” leading the NSA to collect millions of calls it was “not authorized to receive.”

Unlike these past programs, which were subject to congressional oversight, DAS is not. A senior Wyden aide tells WIRED the program takes advantage of numerous “loopholes” in federal privacy law. The fact that it’s effectively run out of the White House, for example, means it is exempt from rules requiring assessments of its privacy impacts. The White House is also exempt from the Freedom of Information Act, reducing the public’s overall ability to shed light on the program.

Because AT&T’s call record collection occurs along a telecommunications “backbone,” protections enshrined under the Electronic Communications Privacy Act may not apply to the program.

Earlier this month, Wyden and other lawmakers in the House and Senate introduced comprehensive privacy legislation known as the Government Surveillance Reform Act. The bill contains numerous provisions that, if enacted, would patch most if not all of these loopholes, effectively rendering the DAS program, in its current form, explicitly illegal.

Read Wyden’s full letter to the US Department of Justice below:

_The Honorable Merrick B. Garland_  
_Attorney General_  
_U.S. Department of Justice_  
_950 Pennsylvania Avenue, NW_  
_Washington, DC 20530-0001_

_Dear Attorney General Garland:_

_I write to request that you clear for public release additional information about the Hemisphere Project. This is a long-running dragnet surveillance program in which the White House pays AT&T to provide all federal, state, local, and Tribal law enforcement agencies the ability to request often-warrantless searches of trillions of domestic phone records._

_In 2013, the New York Times revealed the existence of a surveillance program in which the White House Office of National Drug Control Policy (ONDCP) pays AT&T to mine its customers’ records for the benefit of federal, state, local, and Tribal law enforcement agencies. According to an ONDCP slide deck, AT&T has kept and queries as part of the Hemisphere Project call records going back to 1987, with 4 billion new records being added every day. That slide deck was apparently disclosed by a local law enforcement agency in response to a public information request and was published by the New York Times in 2013._

_The scale of the data available to and routinely searched for the benefit of law enforcement under the Hemisphere Project is stunning in its scope. One law enforcement official described the Hemisphere Project as “AT&T's Super Search Engine” and ... "Google on Steroids,” according to emails released by the Drug Enforcement Administration (DEA) under the Freedom of Information Act. The ONDCP slide deck and an email released by the DEA also reveal that AT&T searches records kept by its wholesale division, which carries communications on behalf of other communications companies and their customers. Another slide deck released by ONDCP and published by the press in 2014 describes the specific capabilities of Hemisphere, including that it can be used to identify alternate numbers used by a target, obtain location data and “two levels of call detail records for one target number” (meaning the phone records of everyone who communicated with the target)._

_The Hemisphere Project has been supported by regular funding from the White House ONDCP since 2009, according to the attached undated white paper that ONDCP provided to my office on October 27, 2022 (Appendix A). That same document reveals that White House funding for this program was suspended by the Obama Administration in 2013, the same year the program was exposed by the press, but continued with other federal funding under a new generic sounding program name, “Data Analytical Services.” ONDCP funding for this surveillance program was quietly resumed by the Trump Administration in 2017, paused again in 2021, the first year of the Biden Administration, and then quietly restarted again in 2022._

_Although the Hemisphere Project is paid for with federal funds, they are delivered to AT&T through an obscure grant program, enabling the program to skip an otherwise mandatory federal privacy review. If the funds came directly from a federal agency, such as the DEA, Hemisphere would have been subjected to a mandatory Privacy Impact Assessment conducted by the Department of Justice (DOJ) Office of Privacy and Civil Liberties, the findings of which would be made public. Instead, ONDCP provides funding for the program through the Houston High Intensity Drug Trafficking Area (HIDTA), one of 33 regional funding organizations as a part of a grant program created by Congress and administered by ONDCP. The HIDTAs distribute federal anti-drug law enforcement grants to state and local agencies, and are governed by a board made up entirely of federal, state and local law enforcement officials._

_ONDCP provided my staff with an undated white paper describing the program and its historical funding levels, but ONDCP directed all questions about Hemisphere to the Houston HIDTA. Officials at the Houston HIDTA provided my office with a briefing on November 7, 2022, and spoke again with my staff again by phone on December 1, 2022. The Houston HIDTA officials told my staff that all Hemisphere requests are sent to a single AT&T analyst located in Atlanta, Georgia, and that any law enforcement officer working for one of the federal, state, local and Tribal law enforcement agencies in the U.S. can contact the AT&T Hemisphere analyst directly to request they run a query, with varying authorization requirements. The Houston HIDTA officials confirmed that Federal and state law enforcement agencies can request a Hemisphere search with a subpoena, which is a directive that many law enforcement agencies can issue themselves (except in California and Texas, where a court order is required by state law). They also explained that Hemisphere searches are not required to be in support of drug-related investigations._

_For the past year, I have urged the DOJ to release dozens of pages of material related to the Hemisphere Project, which it first provided to my office in 2019. This information has been designated “Law Enforcement Sensitive,” which is meant to restrict its public release. I have serious concerns about the legality of this surveillance program, and the materials provided by the DOJ contain troubling information that would justifiably outrage many Americans and other members of Congress. While I have long defended the government’s need to protect classified sources and methods, this surveillance program is not classified and its existence has already been acknowledged by the DOJ in federal court. The public interest in an informed debate about government surveillance far outweighs the need to keep this information secret. To that end, I urge you to promptly clear for public release the material described in Appendix B._

_Thank you for your attention to this important matter._

_Sincerely,_

_Ron Wyden_  
_United States Senator_

Secretive White House Surveillance Program Gives Cops Access to Trillions of US Phone Records

Threat actors are targeting the education, government and business services sectors with a remote access trojan called NetSupport RAT.
"The delivery mechanisms for the NetSupport RAT encompass fraudulent updates, drive-by downloads, utilization of malware loaders (such as GHOSTPULSE), and various forms of phishing campaigns," VMware Carbon Black researchers said in a report shared with The

Malware / Network Security

Threat actors are targeting the education, government and business services sectors with a remote access trojan called **NetSupport RAT**.

"The delivery mechanisms for the NetSupport RAT encompass fraudulent updates, drive-by downloads, utilization of malware loaders (such as GHOSTPULSE), and various forms of phishing campaigns," VMware Carbon Black researchers said in a report shared with The Hacker News.

The cybersecurity firm said it detected no less than 15 new infections related to NetSupport RAT in the last few weeks.

While NetSupport Manager started off as a legitimate remote administration tool for technical assistance and support, malicious actors have misappropriated the tool to their own advantage, using it as a beachhead for subsequent attacks.

NetSupport RAT is typically downloaded onto a victim's computer via deceptive websites and fake browser updates.

In August 2022, Sucuri detailed a campaign in which compromised WordPress sites were being used to display fraudulent Cloudflare DDoS protection pages that led to the distribution of NetSupport RAT.

The use of bogus web browser updates is a tactic often associated with the deployment of a JavaScript-based downloader malware known as SocGholish (aka FakeUpdates), which has also been observed propagating a loader malware codenamed BLISTER.

The Javascript payload subsequently invokes PowerShell to connect to a remote server and retrieve a ZIP archive file containing NetSupport RAT that, upon installation, beacons out to a command-and-control (C2) server.

"Once installed on a victim's device, NetSupport is able to monitor behavior, transfer files, manipulate computer settings, and move to other devices within the network," the researchers said.

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

NetSupport RAT Infections on the Rise - Targeting Government and Business Sectors

GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leak in gf_mpd_parse_string media_tools/mpd.c:75.

1.Version  
./MP4Box -version  
MP4Box - GPAC version 2.3-DEV-rev617-g671976fcc-master  
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io/

Please cite our work in your research:  
GPAC Filters: https://doi.org/10.1145/3339825.3394929  
GPAC: https://doi.org/10.1145/1291233.1291452

GPAC Configuration:  
Features: GPAC\_CONFIG\_LINUX GPAC\_64\_BITS GPAC\_HAS\_IPV6 GPAC\_HAS\_SSL GPAC\_HAS\_SOCK\_UN GPAC\_MINIMAL\_ODF GPAC\_HAS\_QJS GPAC\_HAS\_JPEG GPAC\_HAS\_PNG GPAC\_HAS\_LINUX\_DVB GPAC\_DISABLE\_3D

2.ASAN  
\[DASH\] Updated manifest:  
P#1: start 0 - duration 0 - xlink none  
\[DASH\] Manifest after update:  
P#1: start 0 - duration 0 - xlink none  
\[DASH\] Setting up period start 0 duration 0 xlink none ID DID1  
\[DASH\] AS#1 changed quality to bitrate 10 kbps - Width 1280 Height 720 FPS 30/1 (playback speed 1)  
\[DASH\] AS#2 changed quality to bitrate 120 kbps - Width 384 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] Segment duration unknown - cannot estimate current startNumber  
\[DASH\] Cannot try to download (null)... out of memory ?  
\[DASH\] AS#3 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#4 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#5 changed quality to bitrate 120 kbps - Width 384 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] Adaptation 16: non-video in a video group - disabling it  
\[DASH\] AS#6 changed quality to bitrate 31 kbps (playback speed 1)  
\[DASH\] AS#6 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#7 changed quality to bitrate 120 kbps - Width 448 Height 256 FPS 30/1 (playback speed 1)  
\[DASH\] AS#8 changed quality to bitrate 120 kbps - Width 384 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] AS#9 changed quality to bitrate 120 kbps - Width 448 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] AS#10 changed quality to bitrate 120 kbps - Width 448 Height 208 FPS 30/1 (playback speed 1)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] Segment duration unknown - cannot estimate current startNumber  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASH\] No ROUTE entity on HTTP request  
\[DASH\] AST at init 1621274304781  
\[DASH\] At current time 78047975763 ms: Initializing Timeline: startNumber=1 segmentNumber=78047975 segmentDuration=1.000000 - 0.000 seconds in segment (start range 7.8048e+07)  
\[DASHDmx\] group 0 error locating plugin for segment - mime type video/mp4 name crashes/live\_dash\_track1\_init.mp4: Requested URL is not valid or cannot be found  
Filters not connected:  
fout (dst=id\_000070,sig\_06,src\_000600,time\_26661155,execs\_144902,op\_havoc,rep\_1\_dash.mpd:gpac:segdur=10000/1000:profile=full:!sap:buf=1500:!check\_dur:pssh=v:subs\_sidx=0) (idx=1)

Arg segdur set but not used  
Arg profile set but not used  
Arg !sap set but not used  
Arg buf set but not used  
Arg !check\_dur set but not used  
Arg pssh set but not used  
Arg subs\_sidx set but not used

\=================================================================  
\==2943152==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 20 byte(s) in 2 object(s) allocated from:  
#0 0x7fb5f41339a7 in \_\_interceptor\_strdup ../../../../src/libsanitizer/asan/asan\_interceptors.cpp:454  
#1 0x7fb5f2fd4bbc in gf\_mpd\_parse\_string media\_tools/mpd.c:75  
#2 0x7fb5f2fd4bbc in gf\_mpd\_parse\_common\_representation\_attr media\_tools/mpd.c:665

SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s).

3.Reproduction  
./MP4Box -dash 10000 $poc

4.POC file  
crash.zip

5.Impact  
Malicious files that are opened may cause a crash

6.Credit  
LOVERJIE

CVE-2023-48039: memory leaks in gf_mpd_parse_string media_tools/mpd.c:75 · Issue #2679 · gpac/gpac

GPAC 2.3-DEV-rev617-g671976fcc-master is vulnerable to memory leaks in extract_attributes media_tools/m3u8.c:329.

1.Version  
./MP4Box -version  
MP4Box - GPAC version 2.3-DEV-rev617-g671976fcc-master  
(c) 2000-2023 Telecom Paris distributed under LGPL v2.1+ - http://gpac.io/

Please cite our work in your research:  
GPAC Filters: https://doi.org/10.1145/3339825.3394929  
GPAC: https://doi.org/10.1145/1291233.1291452

GPAC Configuration:  
Features: GPAC\_CONFIG\_LINUX GPAC\_64\_BITS GPAC\_HAS\_IPV6 GPAC\_HAS\_SSL GPAC\_HAS\_SOCK\_UN GPAC\_MINIMAL\_ODF GPAC\_HAS\_QJS GPAC\_HAS\_JPEG GPAC\_HAS\_PNG GPAC\_HAS\_LINUX\_DVB GPAC\_DISABLE\_3D

2.ASAN  
\[M3U8\] Unsupported directive #EXT-X-VERSION:  
\[M3U8\] Attribute SEQUENCE:1 not supported  
\[M3U8\] Invalid #EXT-X-MEDIA: TYPE is missing. Ignoring the line.  
\[M3U8\] Invalid URI (URI=") in EXT-X-MAP  
\[M3U8\] Failed to parse root playlist './crashes/crash4', error = BitStream Not Compliant  
\[DASH\] Error - cannot connect service: MPD creation problem BitStream Not Compliant  
\[DASHDmx\] Error - cannot initialize DASH Client for ./crashes/crash4: BitStream Not Compliant  
Failed to connect filter fin PID crash4 to filter dashin: BitStream Not Compliant  
Blacklisting dashin as output from fin and retrying connections  
Failed to find any filter for URL ./crashes/crash4, disabling destination filter fout  
Filter fin failed to setup: Filter not found for the desired type  
Filters not connected:  
fout (dst=crash4\_dash.mpd:gpac:segdur=500000/1000:profile=full:!sap:buf=1500:!check\_dur:pssh=v:subs\_sidx=0) (idx=1)  
Arg segdur set but not used  
Arg profile set but not used  
Arg !sap set but not used  
Arg buf set but not used  
Arg !check\_dur set but not used  
Arg pssh set but not used  
Arg subs\_sidx set but not used  
Error DASHing file: Filter not found for the desired type

\=================================================================  
\==150880==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 120 byte(s) in 1 object(s) allocated from:  
#0 0x7f7fcaf3ca57 in \_\_interceptor\_calloc ../../../../src/libsanitizer/asan/asan\_malloc\_linux.cpp:154  
#1 0x7f7fc9d73286 in extract\_attributes media\_tools/m3u8.c:329

Indirect leak of 11 byte(s) in 1 object(s) allocated from:  
#0 0x7f7fcaf3ca57 in \_\_interceptor\_calloc ../../../../src/libsanitizer/asan/asan\_malloc\_linux.cpp:154  
#1 0x7f7fc9d7385b in extract\_attributes media\_tools/m3u8.c:345

SUMMARY: AddressSanitizer: 131 byte(s) leaked in 2 allocation(s)..

3.Reproduction  
./MP4Box -dash 500000 $poc

4.POC file  
crash.00.zip

5.Impact  
Memory leaks can cause program performance degradation, system crashes, or unpredictable behavior

6.  Credit  
    jarront

CVE-2023-48090: memory leaks in extract_attributes media_tools/m3u8.c:329 · Issue #2680 · gpac/gpac

Signal’s president reveals the cost of running the privacy-preserving platform—not just to drum up donations, but to call out the for-profit surveillance business models it competes against.

The encrypted messaging and calling app Signal has become a one-of-a-kind phenomenon in the tech world: It has grown from the preferred encrypted messenger for the paranoid privacy elite into a legitimately mainstream service with hundreds of millions of installs worldwide. And it has done this entirely as a nonprofit effort, with no venture capital or monetization model, all while holding its own against the best-funded Silicon Valley competitors in the world, like WhatsApp, Facebook Messenger, Gmail, and iMessage.

Today, Signal is revealing something about what it takes to pull that off—and it’s not cheap. For the first time, the Signal Foundation that runs the app has published a full breakdown of Signal’s operating costs: around $40 million this year, projected to hit $50 million by 2025.

Signal’s president, Meredith Whittaker, says her decision to publish the detailed cost numbers in a blog post for the first time—going well beyond the IRS disclosures legally required of nonprofits—was more than just as a frank appeal for year-end donations. By revealing the price of operating a modern communications service, she says, she wanted to call attention to how competitors pay these same expenses: either by profiting directly from monetizing users’ data or, she argues, by locking users into networks that very often operate with that same corporate surveillance business model.

“By being honest about these costs ourselves, we believe that helps provide a view of the engine of the tech industry, the surveillance business model, that is not always apparent to people,” Whittaker tells WIRED. Running a service like Signal—or WhatsApp or Gmail or Telegram—is, she says, “surprisingly expensive. You may not know that, and there’s a good reason you don’t know that, and it’s because it’s not something that companies who pay those expenses via surveillance _want_ you to know.”

Signal pays $14 million a year in infrastructure costs, for instance, including the price of servers, bandwidth, and storage. It uses about 20 petabytes per year of bandwidth, or 20 million gigabytes, to enable voice and video calling alone, which comes to $1.7 million a year. The biggest chunk of those infrastructure costs, fully $6 million annually, goes to telecom firms to pay for the SMS text messages Signal uses to send registration codes to verify new Signal accounts’ phone numbers. That cost has gone up, Signal says, as telecom firms charge more for those text messages in an effort to offset the shrinking use of SMS in favor of cheaper services like Signal and WhatsApp worldwide.

Another $19 million a year or so out of Signal’s budget pays for its staff. Signal now employs about 50 people, a far larger team than a few years ago. In 2016, Signal had just three full-time employees working in a single room in a coworking space in San Francisco. “People didn’t take vacations,” Whittaker says. “People didn’t get on planes because they didn’t want to be offline if there was an outage or something.” While that skeleton-crew era is over—Whittaker says it wasn’t sustainable for those few overworked staffers—she argues that a team of 50 people is still a tiny number compared to services with similar-sized user bases, which often have thousands of employees.

While Whittaker argues that Signal runs as lean an operation as possible, she also notes that many of its features cost more than they do for other communications platforms, due to the extra cost of enabling those features in privacy-preserving ways. Signal implements encryption, for instance, not just for the content of calls and texts, but for users’ contacts, and even for their user profile names and photos, as well as more obscure features, like users’ searches for animated GIFs. That means simple-looking elements of the app often require far more time-consuming and expensive engineering than would be necessary if they were offered without encryption.

Signal was originally founded with funding from the US State Department’s Open Technology Fund, but the service has since turned to donations to keep afloat. When the Signal Foundation was created in 2018 and WhatsApp cofounder Brian Acton left Facebook to become its president, he donated $50 million. But with Signal’s growing user base and staff, that donation wouldn't cover much more than a year’s current budget for the company. Other major donors continue to cover the foundation’s costs, Whittaker says—Twitter cofounder Jack Dorsey, for instance, has pledged $1 million a year, and others Whittaker declines to name have given similarly large contributions.

But Signal hopes to increasingly rely on donations of as little as $3 that can be made through the app itself. Monthly donations of $5 or more are rewarded with a badge for the user’s account. Those small donations, Signal says, now account for 25 percent of its operating costs, up from 18 percent last year, the first full year after Signal enabled in-app contributions. But for Signal to continue to exist and grow without depending on a few wealthy individuals, Whittaker says small user donations will need to ramp up significantly.

With a nearly $50 million annual budget, can Signal actually survive on those donations? “We have to,” says Whittaker. “Signal needs to find a way to survive in perpetuity because it is _the_ tool that we have to ensure meaningfully private communications.”

Whittaker says that charging users has never been an option—Signal would never have grown its network to a degree that could compete with iMessage or WhatsApp if it hadn’t been free all along. Nor can Signal adopt a venture capital-funded business model that would leave the service vulnerable to investors or shareholders demanding a profitable exit. Exhibit one: Elon Musk’s acquisition of Twitter and his decisions that triggered an exodus of its users. “We’re not going to get leaned on,” says Whittaker. “We’re going to stay myopically focused on our mission, without the kind of pressure to compromise that for-profit tech companies feel. And that pressure is heavy when you recognize the cost to do what we do.”

Given that privacy-focused mission, Whittaker argues that revealing Signal’s costs isn't just about helping to raise money to keep protecting users’ communications, it also serves to call out the rest of the tech industry’s anti-privacy practices.

“The default for all this is surveillance. That’s the water we swim in. So how do we swim upstream? How do we move against this and build something that can perturb that default?” she asks. “I hope being honest about these costs leads people to ask better questions of other tech organizations, to better understand what’s actually happening and how we got into a situation where a handful of companies have such an outsize power globally based on their perfecting this surveillance business model.”

Running Signal Will Soon Cost $50 Million a Year

Red Hat Security Advisory 2023-7262-01 - An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions. Issues addressed include a bypass vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7262.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: open-vm-tools security updateAdvisory ID:        RHSA-2023:7262-01Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7262Issue date:         2023-11-15Revision:           01CVE Names:          CVE-2023-34058====================================================================Summary: An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The Open Virtual Machine Tools are the open source implementation of the VMware Tools. They are a set of guest operating system virtualization components that enhance performance and user experience of virtual machines.Security Fix(es):* open-vm-tools: SAML token signature bypass (CVE-2023-34058)* open-vm-tools: file descriptor hijack vulnerability in the vmware-user-suid-wrapper (CVE-2023-34059)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-34058References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2246080https://bugzilla.redhat.com/show_bug.cgi?id=2246096

Red Hat Security Advisory 2023-7262-01

Red Hat Security Advisory 2023-7261-01 - An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions. Issues addressed include a bypass vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7261.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: open-vm-tools security updateAdvisory ID:        RHSA-2023:7261-01Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7261Issue date:         2023-11-15Revision:           01CVE Names:          CVE-2023-34058====================================================================Summary: An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The Open Virtual Machine Tools are the open source implementation of the VMware Tools. They are a set of guest operating system virtualization components that enhance performance and user experience of virtual machines.Security Fix(es):* open-vm-tools: SAML token signature bypass (CVE-2023-34058)* open-vm-tools: file descriptor hijack vulnerability in the vmware-user-suid-wrapper (CVE-2023-34059)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-34058References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2246080https://bugzilla.redhat.com/show_bug.cgi?id=2246096

Red Hat Security Advisory 2023-7261-01

Red Hat Security Advisory 2023-7260-01 - An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions. Issues addressed include a bypass vulnerability.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7260.jsonRed Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis:           Important: open-vm-tools security updateAdvisory ID:        RHSA-2023:7260-01Product:            Red Hat Enterprise LinuxAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7260Issue date:         2023-11-15Revision:           01CVE Names:          CVE-2023-34058====================================================================Summary: An update for open-vm-tools is now available for Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:The Open Virtual Machine Tools are the open source implementation of the VMware Tools. They are a set of guest operating system virtualization components that enhance performance and user experience of virtual machines.Security Fix(es):* open-vm-tools: SAML token signature bypass (CVE-2023-34058)* open-vm-tools: file descriptor hijack vulnerability in the vmware-user-suid-wrapper (CVE-2023-34059)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2023-34058References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2246080https://bugzilla.redhat.com/show_bug.cgi?id=2246096

Red Hat Security Advisory 2023-7260-01

Microsoft has patched a total of 63 vulnerabilities this Patch Tuesday. Make sure you update as soon as you can.

Another important update round for this month’s Patch Tuesday. Microsoft has patched a total of 63 vulnerabilities in its operating systems. Five of these vulnerabilities qualify as zero-days, with three listed as being actively exploited. Microsoft considers a vulnerability to be a zero-day if it is publicly disclosed or actively exploited with no official fix available.

The Common Vulnerabilities and Exposures (CVE) database lists publicly disclosed computer security flaws. The zero-days patched in these updates are listed as:

CVE-2023-36025: a Windows SmartScreen security feature bypass vulnerability that would allow an attacker to bypass Windows Defender SmartScreen checks and their associated prompts. SmartScreen is a built-in Windows component designed to detect and block known malicious websites and files.

It requires user interaction since the user would have to click on a specially crafted Internet Shortcut (.URL) or a hyperlink pointing to an Internet Shortcut file to be compromised by the attacker. Microsoft listed this vulnerability with the remark “Exploitation Detected.”

CVE-2023-36033: a Windows Desktop Window Manager (DWM) Core Library elevation of privilege (EoP) vulnerability. An attacker who successfully exploited this vulnerability could gain SYSTEM privileges. This vulnerability is also listed with the remark “Exploitation Detected.”

CVE-2023-36036: a Windows Cloud Files Mini Filter Driver EoP vulnerability. An attacker who successfully exploited this vulnerability could gain SYSTEM privileges. This vulnerability is also listed with the remark “Exploitation Detected.”

EoP type of vulnerabilities are typically used in attack chains. Once the attacker has gained entrance, the vulnerabilities allow them to increase their permission level.

CVE-2023-36413: a Microsoft Office security feature bypass vulnerability. Successful exploitation of this vulnerability would allow an attacker to bypass the Office Protected View and open in editing mode rather than protected mode. Full exploitation requires that the attacker sends the target a malicious file and convince them to open it. This is a publicly disclosed vulnerability but there are no known cases of exploitation.

CVE-2023-36038: a vulnerability in ASP.NET that could lead to core denial of service. This vulnerability could be exploited if http requests to .NET 8 RC 1 running on IIS InProcess hosting model are cancelled. Threads counts would increase and an OutOfMemoryException is possible. A successful exploitation might result in a total loss of availability. So, basically an attacker would send requests and then cancel them until the program runs out of memory and crashes. Microsoft notes that this vulnerability was publicly disclosed, however no in-the-wild exploitation has been observed, which is not likely to happen either if the denial of service is the best achievable goal for an attacker.

An extra warning for organizations running Microsoft Exchange Server: Prioritize several new Exchange patches, including CVE-2023-36439, which is a vulnerability that enables attackers to install malicious software on an Exchange server.

**Other vendors**

Other organizations have synchronized their periodic updates with Microsoft. Here are few major ones that you may find in your environment.

**Adobe** has released security updates to address vulnerabilities affecting multiple Adobe products:

*   APSB23-52: Adobe ColdFusion
*   APSB23-53: Adobe RoboHelp Server
*   APSB23-54: Adobe Acrobat and Reader
*   APSB23-55: Adobe InDesign
*   APSB23-56: Adobe Photoshop
*   APSB23-57: Adobe Bridge
*   APSB23-58: Adobe FrameMaker Publishing Server
*   APSB23-60: Adobe InCopy
*   APSB23-61: Adobe Animate
*   APSB23-62: Adobe Dimension
*   APSB23-63: Adobe Media Encoder
*   APSB23-64: Adobe Audition
*   APSB23-65: Adobe Premiere Pro
*   APSB23-66: Adobe After Effects

**Android**’s November updates were released by Google.

**SAP** released its November 2023 Patch Day updates.

**SysAid** released security updates for a zero-day vulnerability that is actively being exploited by a ransomware affiliate.

**We don’t just report on vulnerabilities—we identify them, and prioritize action.**

Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in tow by using Malwarebytes Vulnerability and Patch Management.

Tag

#sap