Plus: The “Clop” gang's ransomware spree, the DC Health Link breach comes into focus, and more.

A US House of Representatives hearing this week about the social media app TikTok did little to clarify lawmaker's specific concerns about the potential national security risks associated with the wildly popular app, but it did vividly underscore the country’s lack of federal data privacy legislation. WIRED also discovered that TikTok paid for influencers popular on its platform to attend a DC rally in support of the service ahead of the hearing. 

Meanwhile, as a possible indictment of former US president Donald Trump looms in New York state, internet users began generating AI images of Trump being arrested, but there are ways to tell that they're fake. WIRED examined the increasingly aggressive and desperate tactics of Iran's government-backed hackers amid mass protest and unrest in the country. Citizen sleuths around the world are using open source intelligence to separate fact from fiction in the mystery of who sabotaged the Nord Stream pipeline. And vulnerabilities keep showing up in ultra-popular photo cropping tools, exposing a host of cropped images all over the world where some or all of the original image can be recovered.

Plus, if you want to know what it's like to be investigated by the US Secret Service—and how to avoid that particular pleasure—we have a full account.

And there's more. Each week, we round up the security news we didn’t cover in-depth ourselves. Click the headlines to read the full stories, and stay safe out there.

People living in the Indian state of Punjab grappled with an internet shutdown for days after police imposed a connectivity blackout while searching for the Sikh activist Amritpal Singh. Singh is a member of the Sikh Waris Punjab De movement and recently evaded arrest. More than 100 of his supporters have been arrested. Punjab's 27 million inhabitants faced mobile data and SMS blocking as well as traffic filtering on certain websites and services. For example, the government appeared to have blocked access to prominent Sikh Twitter accounts, including that of poet Rupi Kaur and the nonprofit United Sikhs. “Punjab Police India continued its crackdown on Waris Punjab De elements wanted on criminal charges,” the government of Punjab said in a Facebook post on Monday. “Amritpal Singh remains a fugitive, and efforts are being made to arrest him.” Protests have erupted in Punjab and around the world over law enforcement treatment of Sikh Waris Punjab De and the internet shutdown.

A vulnerability in file transfer software from Fortra known as GoAnywhere has been repeatedly exploited by the notorious, Russia-based Clop ransomware group to target dozens or possibly more than a hundred victims in recent days. The cybercrminal group has added entries on numerous organizations to its dark web site, where Clop attempts to extort money from victims by publishing samples of data they've stolen and threatening to leak more if targets don't pay. TechCrunch confirmed on Thursday that the City of Toronto is one of the victims of the spree. “Today, the City of Toronto has confirmed that unauthorized access to City data did occur through a third-party vendor. The access is limited to files that were unable to be processed through the third-party secure file transfer system," officials said in a statement. TechCrunch has also uncovered details about problems with Fortra's response to the discovery of the vulnerability.

The company that runs the Washington DC health insurance marketplace DC Health Link suffered a breach earlier this month that exposed sensitive and personal data from tens of thousands of area customers, including from some US lawmakers and congressional staff. The information included names, email addresses, dates of birth, mail addresses, Social Security numbers, and policy details. The DC Health Benefit Exchange Authority acknowledged the breach on March 7. The entity that has claimed credit for the breach, who goes by the handle “Denfur,” posted samples of data from the attack on BreachForums. Denfur subsequently posted “Glory to Russia!” and that the “intended target was US politicians and members of US government." In an interview with CyberScoop on an encrypted chat service, Denfur claimed not to be concerned about suffering repercussions from law enforcement. “If anything, I’m more worried about my country trying to do a favour for the US and myself or group becoming a sort of bargaining chip,” Denfur said. “The current time brings uncertainty.”

The alleged “pompompurin” administrator of the popular cybercriminal public square BreachForums—the same site Denfur used against DC Health Link—was arrested in New York state earlier this month, but a new leader known as “Baphomet” had come forward, claiming to have a plan to keep the platform going. On Tuesday, though, Baphomet changed course, claiming that someone had gained access to the BreachForums backend and that law enforcement may now control pompompurin's privileged administrator accounts. “This will be my final update on Breached, as I've decided to shut it down,” Baphomet wrote. “I'm aware this news will not please anyone, but it's the only safe decision now that I've confirmed that the glowies likely have access to Poms machine.”

India Shut Down Mobile Internet in Punjab Amid Manhunt for Amritpal Singh

OpenAI on Friday disclosed that a bug in the Redis open source library was responsible for the exposure of other users' personal information and chat titles in the upstart's ChatGPT service earlier this week.
The glitch, which came to light on March 20, 2023, enabled certain users to view brief descriptions of other users' conversations from the chat history sidebar, prompting the company to

Artificial Intelligence / Data Security

OpenAI on Friday disclosed that a bug in the Redis open source library was responsible for the exposure of other users' personal information and chat titles in the upstart's ChatGPT service earlier this week.

The glitch, which came to light on March 20, 2023, enabled certain users to view brief descriptions of other users' conversations from the chat history sidebar, prompting the company to temporarily shut down the chatbot.

"It's also possible that the first message of a newly-created conversation was visible in someone else's chat history if both users were active around the same time," the company said.

The bug, it further added, originated in the redis-py library, leading to a scenario where canceled requests could cause connections to be corrupted and return unexpected data from the database cache, in this case, information belonging to an unrelated user.

To make matters worse, the San Francisco-based AI research company said it introduced a server-side change by mistake that led to a surge in request cancellations, thereby upping the error rate.

While the problem has since been addressed, OpenAI noted that the issue may have had more implications elsewhere, potentially revealing payment-related information of 1.2% of the ChatGPT Plus subscribers on March 20 between 1-10 a.m. PT.

WEBINAR

Discover the Hidden Dangers of Third-Party SaaS Apps

Are you aware of the risks associated with third-party app access to your company's SaaS apps? Join our webinar to learn about the types of permissions being granted and how to minimize risk.

RESERVE YOUR SEAT

This included another active user's first and last name, email address, payment address, the last four digits (only) of a credit card number, and credit card expiration date. It emphasized that full credit card numbers were not exposed.

The company said it has reached out to affected users to notify them of the inadvertent leak. It also said it "added redundant checks to ensure the data returned by our Redis cache matches the requesting user."

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

OpenAI Reveals Redis Bug Behind ChatGPT User Data Exposure Incident

TensorFlow is an open source platform for machine learning. Versions prior to 2.12.0 and 2.11.1 have a null point error in QuantizedMatMulWithBiasAndDequantize with MKL enabled. A fix is included in TensorFlow version 2.12.0 and version 2.11.1.

@@ -12,7 +12,7 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. \==============================================================================\*/ #if defined(INTEL\_MKL) && defined(ENABLE\_MKL) #if defined(INTEL\_MKL) #define EIGEN\_USE\_THREADS  
#include <functional\> @@ -64,10 +64,10 @@ TEST\_F(QuantizedMatMulTest, Small\_withBias) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {1, 2, 3, 4}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -116,10 +116,10 @@ TEST\_F(QuantizedMatMulTest, Small\_withNegBias) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {100, -200, 300, -400}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -178,10 +178,10 @@ TEST\_F(QuantizedMatMulTest, Small\_WithNegInp) { AddInputFromArray<qint8>(TensorShape({3, 2}), {1, 4, 2, 5, 3, 6}); // Bias AddInputFromArray<float\>(TensorShape({2}), {10.0f, 20.0f}); AddInputFromArray<float\>(TensorShape({1}), {-12.0f}); AddInputFromArray<float\>(TensorShape({1}), {243.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {-12.0f}); AddInputFromArray<float\>(TensorShape({}), {243.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // First calculate C = A \* B, @@ -240,12 +240,12 @@ TEST\_F(QuantizedMatMulTest, Small\_withBiasAndReq) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {10, -20, 30, -40}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -308,12 +308,12 @@ TEST\_F(QuantizedMatMulTest, Small\_withBiasAndDeq) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {10, -20, 30, -40}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -375,10 +375,10 @@ TEST\_F(QuantizedMatMulTest, Small\_withBiasAndRelu) { {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<float\>(TensorShape({4}), {100.0f, -200.0f, 300.0f, -400.0f}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -431,12 +431,12 @@ TEST\_F(QuantizedMatMulTest, Small\_withBiasAndReluAndReq) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {10, -20, 30, -40}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f});  
TF\_ASSERT\_OK(RunOpKernel()); // Here are the results we expect, from hand calculations: @@ -502,10 +502,10 @@ TEST\_F(QuantizedMatMulTest, Small\_withWeightCached) { AddInputFromArray<qint8>(TensorShape({3, 4}), {7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18}); AddInputFromArray<qint32>(TensorShape({4}), {1, 2, 3, 4}); AddInputFromArray<float\>(TensorShape({1}), {0}); AddInputFromArray<float\>(TensorShape({1}), {255.0f}); AddInputFromArray<float\>(TensorShape({1}), {-127.0f}); AddInputFromArray<float\>(TensorShape({1}), {127.0f}); AddInputFromArray<float\>(TensorShape({}), {0}); AddInputFromArray<float\>(TensorShape({}), {255.0f}); AddInputFromArray<float\>(TensorShape({}), {-127.0f}); AddInputFromArray<float\>(TensorShape({}), {127.0f});  
int64 start\_time = Env::Default()->NowMicros(); TF\_ASSERT\_OK(RunOpKernel()); @@ -543,4 +543,4 @@ TEST\_F(QuantizedMatMulTest, Small\_withWeightCached) {  
} // namespace tensorflow  
#endif // INTEL\_MKL && ENABLE\_MKL #endif // INTEL\_MKL

CVE-2023-25670: Merge pull request #59437 from Intel-tensorflow:amin/fix-qmatmul · tensorflow/tensorflow@8a47a39

A heap-based buffer overflow was discovered in upx, during the generic pointer 'p' points to an inaccessible address in func get_le32(). The problem is essentially caused in PackLinuxElf32::elf_lookup() at p_lx_elf.cpp:5382.

**What's the problem (or question)?**

Multi heap-based buffer overflows were discovered in upx, during the genric pointer 'p' points to an inaccessible address in func get\_le32(). The issue can be triggered by different places, which can cause a denial of service. The issue is diff from issue365

ASAN reports:

\==112024==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61d00001f3b1 at pc 0x0000005292cb bp 0x7fffc3995640 sp 0x7fffc3995630
READ of size 4 at 0x61d00001f3b1 thread T0
    #0 0x5292ca in get\_le32(void const\*) /home/test/Desktop/EVAULATION/upx/src/bele.h:164
    #1 0x5292ca in N\_BELE\_RTP::LEPolicy::get32(void const\*) const /home/test/Desktop/EVAULATION/upx/src/bele\_policy.h:192
    #2 0x4589c1 in Packer::get\_te32(void const\*) const /home/test/Desktop/EVAULATION/upx/src/packer.h:296
    #3 0x4589c1 in PackLinuxElf32::elf\_lookup(char const\*) const /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:5382
    #4 0x463d30 in PackLinuxElf32::PackLinuxElf32help1(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:315
    #5 0x464e96 in PackLinuxElf32Le::PackLinuxElf32Le(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.h:395
    #6 0x464e96 in PackLinuxElf32x86::PackLinuxElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4800
    #7 0x464e96 in PackBSDElf32x86::PackBSDElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4817
    #8 0x464e96 in PackFreeBSDElf32x86::PackFreeBSDElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4828
    #9 0x4f337a in PackMaster::visitAllPackers(Packer\* (\*)(Packer\*, void\*), InputFile\*, options\_t const\*, void\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:190
    #10 0x4f50f9 in PackMaster::getUnpacker(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:248
    #11 0x4f521f in PackMaster::unpack(OutputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:266
    #12 0x52a1e6 in do\_one\_file(char const\*, char\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:160
    #13 0x52a69e in do\_files(int, int, char\*\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:271
    #14 0x403ace in main /home/test/Desktop/EVAULATION/upx/src/main.cpp:1538
    #15 0x7efc08e6182f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #16 0x404828 in \_start (/home/test/Desktop/EVAULATION/upx/src/upx.out+0x404828)

0x61d00001f3b1 is located 189 bytes to the right of 2164-byte region \[0x61d00001ea80,0x61d00001f2f4)
allocated by thread T0 here:
    #0 0x7efc09a55602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x42732a in MemBuffer::alloc(unsigned long long) /home/test/Desktop/EVAULATION/upx/src/mem.cpp:194

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/test/Desktop/EVAULATION/upx/src/bele.h:164 get\_le32(void const\*)
Shadow bytes around the buggy address:
  0x0c3a7fffbe20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fffbe30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fffbe40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c3a7fffbe50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 fa
  0x0c3a7fffbe60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
\=>0x0c3a7fffbe70: fa fa fa fa fa fa\[fa\]fa fa fa fa fa fa fa fa fa
  0x0c3a7fffbe80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3a7fffbe90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3a7fffbea0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3a7fffbeb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c3a7fffbec0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
\==112024\==ABORTING

Debug

Program received signal SIGSEGV, Segmentation fault.
0x000000000066f8f8 in get\_le32 (p=0xa1fffd) at bele.h:164
164        return ACC\_UA\_GET\_LE32(p);
\[ Legend: Modified register | Code | Heap | Stack | String \]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x0               
$rbx   : 0xa7ce93          
$rcx   : 0x2               
$rdx   : 0xae              
$rsp   : 0x00007fffffffcc18  →  0x000000000051249b  →  <PackLinuxElf32::elf\_lookup(char+0> xor eax, ebp
$rbp   : 0x8e8223e2        
$rsi   : 0x0000000000a1fffd  →  0x0000000000a1fffd
$rdi   : 0x00000000009ed3c0  →  0x00000000007cd9c0  →  0x000000000066fe00  →  <N\_BELE\_RTP::LEPolicy::~LEPolicy()+0> lea rsp, \[rsp-0x98\]
$rip   : 0x000000000066f8f8  →  <N\_BELE\_RTP::LEPolicy::get32(void+0> mov eax, DWORD PTR \[rsi\]
$r8    : 0x1f              
$r9    : 0x3fdf            
$r10   : 0xae              
$r11   : 0x1d9577c0        
$r12   : 0x0000000000a00030  →  0x00000000007267a0  →  <vtable+0> add BYTE PTR \[rax\], al
$r13   : 0x0000000000a1fffd  →  0x0000000000a1fffd
$r14   : 0x0000000000a00a51  →  0x0000000000000000
$r15   : 0x00000000007cd9c0  →  0x000000000066fe00  →  <N\_BELE\_RTP::LEPolicy::~LEPolicy()+0> lea rsp, \[rsp-0x98\]
$eflags: \[carry PARITY adjust ZERO sign trap INTERRUPT direction overflow RESUME virtualx86 identification\]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000 
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007fffffffcc18│+0x0000: 0x000000000051249b  →  <PackLinuxElf32::elf\_lookup(char+0> xor eax, ebp     ← $rsp
0x00007fffffffcc20│+0x0008: 0x00000000006cdffe  →  "JNI\_OnLoad"
0x00007fffffffcc28│+0x0010: 0x0000000200000000
0x00007fffffffcc30│+0x0018: 0x000000000900457f
0x00007fffffffcc38│+0x0020: 0x0000000000000068 ("h"?)
0x00007fffffffcc40│+0x0028: 0x0000000000000000
0x00007fffffffcc48│+0x0030: 0x0000000000070000
0x00007fffffffcc50│+0x0038: 0x0000000000000000
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x66f8e7 <N\_BELE\_RTP::LEPolicy::get32(void+0> mov    rcx, QWORD PTR \[rsp+0x8\]
     0x66f8ec <N\_BELE\_RTP::LEPolicy::get32(void+0> mov    rdx, QWORD PTR \[rsp\]
     0x66f8f0 <N\_BELE\_RTP::LEPolicy::get32(void+0> lea    rsp, \[rsp+0x98\]
 →   0x66f8f8 <N\_BELE\_RTP::LEPolicy::get32(void+0> mov    eax, DWORD PTR \[rsi\]
     0x66f8fa <N\_BELE\_RTP::LEPolicy::get32(void+0> ret    
     0x66f8fb                  nop    DWORD PTR \[rax+rax\*1+0x0\]
     0x66f900 <N\_BELE\_RTP::LEPolicy::get64(void+0> lea    rsp, \[rsp-0x98\]
     0x66f908 <N\_BELE\_RTP::LEPolicy::get64(void+0> mov    QWORD PTR \[rsp\], rdx
     0x66f90c <N\_BELE\_RTP::LEPolicy::get64(void+0> mov    QWORD PTR \[rsp+0x8\], rcx
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── source:bele.h+164 ────
    159     }
    160     
    161     inline unsigned get\_le32(const void \*p)
    162     {
    163     #if defined(ACC\_UA\_GET\_LE32)
 →  164         return ACC\_UA\_GET\_LE32(p);
    165     #else
    166         return acc\_ua\_get\_le32(p);
    167     #endif
    168     }
    169     
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
\[#0\] Id 1, Name: "upx.out", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
\[#0\] 0x66f8f8 → get\_le32(p=0xa1fffd)
\[#1\] 0x66f8f8 → N\_BELE\_RTP::LEPolicy::get32(this=0x9ed3c0 <N\_BELE\_RTP::le\_policy>, p=0xa1fffd)
\[#2\] 0x51249b → Packer::get\_te32(this=0xa00030, p=0xa1fffd)
\[#3\] 0x51249b → PackLinuxElf32::elf\_lookup(this=0xa00030, name=0x6cdffe "JNI\_OnLoad")
\[#4\] 0x529509 → PackLinuxElf32::PackLinuxElf32help1(this=0xa00030, f=0x7fffffffce10)
\[#5\] 0x52c65e → PackLinuxElf32Le::PackLinuxElf32Le(f=0x7fffffffce10, this=0xa00030)
\[#6\] 0x52c65e → PackLinuxElf32x86::PackLinuxElf32x86(f=0x7fffffffce10, this=0xa00030)
\[#7\] 0x52c65e → PackBSDElf32x86::PackBSDElf32x86(f=0x7fffffffce10, this=0xa00030)
\[#8\] 0x52c65e → PackFreeBSDElf32x86::PackFreeBSDElf32x86(this=0xa00030, f=0x7fffffffce10)
\[#9\] 0x60448c → PackMaster::visitAllPackers(func=0x602c30 <try\_unpack(Packer\*, void\*)>, f=0x7fffffffce10, o=0x7fffffffcfc8, user=0x7fffffffce10)
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
gef➤  bt
#0  0x000000000066f8f8 in get\_le32 (p=0xa1fffd) at bele.h:164
#1  N\_BELE\_RTP::LEPolicy::get32 (this=0x9ed3c0 <N\_BELE\_RTP::le\_policy>, p=0xa1fffd) at bele\_policy.h:192
#2  0x000000000051249b in Packer::get\_te32 (this=0xa00030, p=0xa1fffd) at packer.h:296
#3  PackLinuxElf32::elf\_lookup (this=0xa00030, name=0x6cdffe "JNI\_OnLoad") at p\_lx\_elf.cpp:5382
#4  0x0000000000529509 in PackLinuxElf32::PackLinuxElf32help1 (this=this@entry=0xa00030, f=f@entry=0x7fffffffce10) at p\_lx\_elf.cpp:315
#5  0x000000000052c65e in PackLinuxElf32Le::PackLinuxElf32Le (f=0x7fffffffce10, this=0xa00030) at p\_lx\_elf.h:395
#6  PackLinuxElf32x86::PackLinuxElf32x86 (f=0x7fffffffce10, this=0xa00030) at p\_lx\_elf.cpp:4800
#7  PackBSDElf32x86::PackBSDElf32x86 (f=0x7fffffffce10, this=0xa00030) at p\_lx\_elf.cpp:4817
#8  PackFreeBSDElf32x86::PackFreeBSDElf32x86 (this=0xa00030, f=0x7fffffffce10) at p\_lx\_elf.cpp:4828
#9  0x000000000060448c in PackMaster::visitAllPackers (func=0x602c30 <try\_unpack(Packer\*, void\*)>, f=0x7fffffffce10, o=0x7fffffffcfc8, user=0x7fffffffce10) at packmast.cpp:190
#10 0x00000000006072ca in PackMaster::getUnpacker (f=<optimized out>) at packmast.cpp:248
#11 PackMaster::unpack (this=0x7fffffffcfb0, fo=0x7fffffffcee0) at packmast.cpp:266
#12 0x0000000000670dc5 in do\_one\_file (iname=iname@entry=0x7fffffffdf15 "id:000089,sig:11,src:001286,op:MOpt-core-havoc,rep:2", oname=oname@entry=0x7fffffffd550 "/dev/null") at work.cpp:160
#13 0x000000000067157c in do\_files (i=i@entry=0x4, argc=0x5, argv=0x7fffffffdac8) at work.cpp:271
#14 0x00000000004056a1 in main (argc=0x5, argv=0x7fffffffdac8) at main.cpp:1538

Deferencing a generic poniter 'p' trigger the overflow.

gef➤  p \*p
Attempt to dereference a generic pointer.
gef➤  p p
$1 = (const void \*) 0xa1fffd

Essentially, the problem is caused in PackLinuxElf32::elf\_lookup() at p\_lx\_elf.cpp:5382

do if (0\==((h ^ get\_te32(hp))>>1)) {
    unsigned st\_name = get\_te32(&dsp->st\_name);
    char const \*const p = get\_str\_name(st\_name, (unsigned)-1);
    if (0\==strcmp(name, p)) {
        return dsp;
    }
} while (++dsp, 0\==(1u& get\_te32(hp++)));

Several locations will also trigger vulnerabilities:  
PackLinuxElf32::elf\_lookup() at p\_lx\_elf.cpp:5368

unsigned const w = get\_te32(&bitmask\[(n\_bitmask -1) & (h>>5)\]);

PackLinuxElf64::elf\_lookup() at p\_lx\_elf.cpp:5404

for (si= get\_te32(&buckets\[m\]); 0!=si; si= get\_te32(&chains\[si\]))

PackLinuxElf32::elf\_lookup() at p\_lx\_elf.cpp:5349

for (si= get\_te32(&buckets\[m\]); 0!=si; si= get\_te32(&chains\[si\])) {
            char const \*const p= get\_dynsym\_name(si, (unsigned)-1);
            if (0\==strcmp(name, p)) {
                return &dynsym\[si\];
            }
        }

**What should have happened?**

Decompress a crafted/suspicious file.

**Do you have an idea for a solution?**

We are very grateful to @jreiser for patching the bucket in p\_lx\_elf.cpp in the issue 365. However, in fact, all places involving get\_te32 () should be strengthened in upx, especially in p\_lx\_elf.cpp. The four positions we reported should be patched at least:

1.  p\_lx\_elf.cpp:5382
2.  p\_lx\_elf.cpp:5368
3.  p\_lx\_elf.cpp:5404
4.  p\_lx\_elf.cpp:5349

**How can we reproduce the issue?**

1.  compile upx with address-sanitize
2.  execute cmd

upx.out -df $PoC -o /dev/null

p\_lx\_elf.cpp:5382  
Poc can be found here.

p\_lx\_elf.cpp:5368  
Poc can be found here.

p\_lx\_elf.cpp:5404  
Poc can be found here.

p\_lx\_elf.cpp:5349  
Poc can be found here.

**Please tell us details about your environment.**

*   UPX version used (upx --version):

upx 4.0.0-git-c6b9e3c62d15 (latest-devel-branch)
UCL data compression library 1.03
zlib data compression library 1.2.8
LZMA SDK version 4.43

*   Host Operating System and version:  
    Ubuntu 16.04 64-bit
*   Host CPU architecture:  
    Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz with 8GB
*   Target Operating System and version:  
    same as Host
*   Target CPU architecture:  
    same as Host

CVE-2021-43311: [bug] multi heap buffer overflows in get_le32() · Issue #380 · upx/upx

A heap-based buffer overflow was discovered in upx, during the variable 'bucket' points to an inaccessible address. The issue is being triggered in the function PackLinuxElf64::invert_pt_dynamic at p_lx_elf.cpp:5239.

**What's the problem (or question)?**

A heap-based buffer overflow was discovered in upx, during the variable 'bucket' points to an inaccessible address. The issue is being triggered in the function PackLinuxElf64::invert\_pt\_dynamic at p\_lx\_elf.cpp:5239.

ASAN reports:

\==110294==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x63000000f760 at pc 0x000000466f38 bp 0x7ffcebb0b6a0 sp 0x7ffcebb0b690
READ of size 4 at 0x63000000f760 thread T0
    #0 0x466f37 in PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE64, LE64, LE64> > const\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:5239
    #1 0x46f660 in PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE64, LE64, LE64> > const\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:5127
    #2 0x46f660 in PackLinuxElf64::PackLinuxElf64help1(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:795
    #3 0x470479 in PackLinuxElf64Le::PackLinuxElf64Le(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.h:407
    #4 0x470479 in PackLinuxElf64amd::PackLinuxElf64amd(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:1008
    #5 0x4f34b2 in PackMaster::visitAllPackers(Packer\* (\*)(Packer\*, void\*), InputFile\*, options\_t const\*, void\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:194
    #6 0x4f50f9 in PackMaster::getUnpacker(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:248
    #7 0x4f521f in PackMaster::unpack(OutputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:266
    #8 0x52a1e6 in do\_one\_file(char const\*, char\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:160
    #9 0x52a69e in do\_files(int, int, char\*\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:271
    #10 0x403ace in main /home/test/Desktop/EVAULATION/upx/src/main.cpp:1538
    #11 0x7f8a7e1c882f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #12 0x404828 in \_start (/home/test/Desktop/EVAULATION/upx/src/upx.out+0x404828)

0x63000000f760 is located 0 bytes to the right of 62304-byte region \[0x630000000400,0x63000000f760)
allocated by thread T0 here:
    #0 0x7f8a7edbc602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x42732a in MemBuffer::alloc(unsigned long long) /home/test/Desktop/EVAULATION/upx/src/mem.cpp:194

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:5239 PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE64, LE64, LE64> \> const\*)
Shadow bytes around the buggy address:
  0x0c607fff9e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c607fff9ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c607fff9eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c607fff9ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c607fff9ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x0c607fff9ee0: 00 00 00 00 00 00 00 00 00 00 00 00\[fa\]fa fa fa
  0x0c607fff9ef0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c607fff9f00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c607fff9f10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c607fff9f20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c607fff9f30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
\==110294\==ABORTING

Then analysis the reasons for segv by debugging:

Program received signal SIGSEGV, Segmentation fault.
0x000000000053b1a8 in PackLinuxElf64::invert\_pt\_dynamic (this=this@entry=0xa00030, dynp=<optimized out\>) at p\_lx\_elf.cpp:5239
5239                if (buckets\[j\]) {
\[ Legend: Modified register | Code | Heap | Stack | String \]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x0               
$rbx   : 0x0000000000a00030  →  0x0000000000726a30  →  <vtable+0> add BYTE PTR \[rax\], al
$rcx   : 0x180             
$rdx   : 0xc00             
$rsp   : 0x00007fffffffcbf0  →  0x000000000065fa86  →  <mem\_size(unsigned+0> mov rax, QWORD PTR \[rsp+0x10\]
$rbp   : 0xffffffff        
$rsi   : 0x7aa9            
$rdi   : 0x0000000000a01548  →  0x480000104fe81024
$rip   : 0x000000000053b1a8  →  <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov eax, DWORD PTR \[rdi+rsi\*4+0x14\]
$r8    : 0x12              
$r9    : 0xffe0            
$r10   : 0xc10             
$r11   : 0x7               
$r12   : 0x8               
$r13   : 0x180             
$r14   : 0x0000000000a0f4d8  →  0x000000000000000d
$r15   : 0x0               
$eflags: \[carry PARITY adjust ZERO sign trap INTERRUPT direction overflow RESUME virtualx86 identification\]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000 
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007fffffffcbf0│+0x0000: 0x000000000065fa86  →  <mem\_size(unsigned+0> mov rax, QWORD PTR \[rsp+0x10\]     ← $rsp
0x00007fffffffcbf8│+0x0008: 0x0000000000400298  →   add eax, DWORD PTR \[rax\]
0x00007fffffffcc00│+0x0010: 0x000000000000ffe0
0x00007fffffffcc08│+0x0018: 0x000000000000f360
0x00007fffffffcc10│+0x0020: 0x00007ffff7352260  →  <read+16> cmp rax, 0xfffffffffffff001
0x00007fffffffcc18│+0x0028: 0x000000000000f360
0x00007fffffffcc20│+0x0030: 0x00007ffff7362447  →  <lseek64+7> cmp rax, 0xfffffffffffff001
0x00007fffffffcc28│+0x0038: 0x0000000000539692  →  <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov rax, QWORD PTR \[rsp+0x10\]
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x53b197 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    rcx, QWORD PTR \[rsp+0x8\]
     0x53b19c <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    rdx, QWORD PTR \[rsp\]
     0x53b1a0 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> lea    rsp, \[rsp+0x98\]
 →   0x53b1a8 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    eax, DWORD PTR \[rdi+rsi\*4+0x14\]
     0x53b1ac <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> test   eax, eax
     0x53b1ae <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> je     0x53b235 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,  LE32,  LE64,  LE64,  LE64> \> const\*)+7109>
     0x53b1b4 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> lea    rsp, \[rsp-0x98\]
     0x53b1bc <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    QWORD PTR \[rsp\], rdx
     0x53b1c0 <PackLinuxElf64::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    QWORD PTR \[rsp+0x8\], rcx
───────────────────────────────────────────────────────────────────────────────────────────────────────────────── source:p\_lx\_elf.cpp+5239 ────
   5234             unsigned     const \*const hasharr = &buckets\[n\_bucket\]; (void)hasharr;
   5235           //unsigned     const \*const gashend = &hasharr\[n\_bucket\];  // minimum, except:
   5236             // Rust and Android trim unused zeroes from high end of hasharr\[\]
   5237             unsigned bmax = 0;
   5238             for (unsigned j= 0; j < n\_bucket; ++j) {
 → 5239                 if (buckets\[j\]) {
   5240                     if (buckets\[j\] < symbias) {
   5241                         char msg\[50\]; snprintf(msg, sizeof(msg),
   5242                                 "bad DT\_GNU\_HASH bucket\[%d\] < symbias{%#x}\\n",
   5243                                 buckets\[j\], symbias);
   5244                         throwCantPack(msg);
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
\[#0\] Id 1, Name: "upx.out", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
\[#0\] 0x53b1a8 → PackLinuxElf64::invert\_pt\_dynamic(this=0xa00030, dynp=<optimized out>)
\[#1\] 0x53d654 → PackLinuxElf64::invert\_pt\_dynamic(dynp=<optimized out>, this=0xa00030)
\[#2\] 0x53d654 → PackLinuxElf64::PackLinuxElf64help1(this=0xa00030, f=0x7fffffffce10)
\[#3\] 0x53f186 → PackLinuxElf64Le::PackLinuxElf64Le(f=0x7fffffffce10, this=0xa00030)
\[#4\] 0x53f186 → PackLinuxElf64amd::PackLinuxElf64amd(this=0xa00030, f=0x7fffffffce10)
\[#5\] 0x6048ac → PackMaster::visitAllPackers(func=0x602c30 <try\_unpack(Packer\*, void\*)>, f=0x7fffffffce10, o=0x7fffffffcfc8, user=0x7fffffffce10)
\[#6\] 0x6072ca → PackMaster::getUnpacker(f=<optimized out>)
\[#7\] 0x6072ca → PackMaster::unpack(this=0x7fffffffcfb0, fo=0x7fffffffcee0)
\[#8\] 0x670dc5 → do\_one\_file(iname=0x7fffffffdf12 "id:000036,sig:11,src:000541+000827,op:MOpt-splice,rep:2", oname=0x7fffffffd550 "/dev/null")
\[#9\] 0x67157c → do\_files(i=0x4, argc=0x5, argv=0x7fffffffdac8)

The instruction to crash is, corresponds to the bucket \[j\] in the source code

mov    eax, DWORD PTR \[rdi+rsi\*4+0x14\]

The register rdi and rsi are:

$rsi   : 0x7aa9            
$rdi   : 0x0000000000a01548

The DWORD PTR pointer to 0xa20000, where is a invalid address.

gef➤  x /10xg 0xa20000
0xa20000:    Cannot access memory at address 0xa20000

**What should have happened?**

Decompress a crafted/suspicious file.

**Do you have an idea for a solution?**

A boundary check is needed for loop variable 'j' because the size allocated for variable 'buckets' is limited.

upx\_uint64\_t const \*const bitmask = (upx\_uint64\_t const \*)(void const \*)&gashtab\[4\];
unsigned     const \*const buckets = (unsigned const \*)&bitmask\[n\_bitmask\];
unsigned     const \*const hasharr = &buckets\[n\_bucket\]; (void)hasharr;
//unsigned     const \*const gashend = &hasharr\[n\_bucket\];  // minimum, except:
// Rust and Android trim unused zeroes from high end of hasharr\[\]
unsigned bmax = 0;
for (unsigned j= 0; j < n\_bucket; ++j) {
    if (buckets\[j\]) {
        if (buckets\[j\] < symbias) {
            char msg\[50\]; snprintf(msg, sizeof(msg),
                                   "bad DT\_GNU\_HASH bucket\[%d\] < symbias{%#x}\\n",
                                   buckets\[j\], symbias);
            throwCantPack(msg);
        }
        if (bmax < buckets\[j\]) {
            bmax = buckets\[j\];
        }
    }
}

**How can we reproduce the issue?**

1.  compile upx with address-sanitize
2.  execute cmd

upx.out -df $PoC -o /dev/null

Poc can be found here.

**Please tell us details about your environment.**

*   UPX version used (upx --version):

upx 4.0.0-git-c6b9e3c62d15 (latest-devel-branch)
UCL data compression library 1.03
zlib data compression library 1.2.8
LZMA SDK version 4.43

*   Host Operating System and version:  
    Ubuntu 16.04 64-bit
*   Host CPU architecture:  
    Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz with 8GB
*   Target Operating System and version:  
    same as Host
*   Target CPU architecture:  
    same as Host

CVE-2021-43312: [bug] heap buffer overflow in PackLinuxElf64::invert_pt_dynamic at p_lx_elf.cpp:5239 · Issue #379 · upx/upx

A heap-based buffer overflow was discovered in upx, during the variable 'bucket' points to an inaccessible address. The issue is being triggered in the function PackLinuxElf32::invert_pt_dynamic at p_lx_elf.cpp:1688.

**What's the problem (or question)?**

A heap-based buffer overflow was discovered in upx, during the variable 'bucket' points to an inaccessible address. The issue is being triggered in the function PackLinuxElf32::invert\_pt\_dynamic at p\_lx\_elf.cpp:1688.

ASAN reports:

\==110358==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600000fed9 at pc 0x00000045acc8 bp 0x7ffd88c9b020 sp 0x7ffd88c9b010
READ of size 4 at 0x61600000fed9 thread T0
    #0 0x45acc7 in PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:1688
    #1 0x463ba5 in PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> > const\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:1583
    #2 0x463ba5 in PackLinuxElf32::PackLinuxElf32help1(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:305
    #3 0x464e96 in PackLinuxElf32Le::PackLinuxElf32Le(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.h:395
    #4 0x464e96 in PackLinuxElf32x86::PackLinuxElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4800
    #5 0x464e96 in PackBSDElf32x86::PackBSDElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4817
    #6 0x464e96 in PackFreeBSDElf32x86::PackFreeBSDElf32x86(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:4828
    #7 0x4f337a in PackMaster::visitAllPackers(Packer\* (\*)(Packer\*, void\*), InputFile\*, options\_t const\*, void\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:190
    #8 0x4f50f9 in PackMaster::getUnpacker(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:248
    #9 0x4f521f in PackMaster::unpack(OutputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:266
    #10 0x52a1e6 in do\_one\_file(char const\*, char\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:160
    #11 0x52a69e in do\_files(int, int, char\*\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:271
    #12 0x403ace in main /home/test/Desktop/EVAULATION/upx/src/main.cpp:1538
    #13 0x7ff33c8dc82f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x404828 in \_start (/home/test/Desktop/EVAULATION/upx/src/upx.out+0x404828)

0x61600000fed9 is located 1 bytes to the right of 600-byte region \[0x61600000fc80,0x61600000fed8)
allocated by thread T0 here:
    #0 0x7ff33d4d0602 in malloc (/usr/lib/x86\_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x42732a in MemBuffer::alloc(unsigned long long) /home/test/Desktop/EVAULATION/upx/src/mem.cpp:194

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:1688 PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16, LE32, LE32, LE32, LE32> \> const\*)
Shadow bytes around the buggy address:
  0x0c2c7fff9f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2c7fff9f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c2c7fff9fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x0c2c7fff9fd0: 00 00 00 00 00 00 00 00 00 00 00\[fa\]fa fa fa fa
  0x0c2c7fff9fe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2c7fff9ff0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2c7fffa000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2c7fffa010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2c7fffa020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
\==110358\==ABORTING

Then analysis the reasons for segv by debugging:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000527258 in PackLinuxElf32::invert\_pt\_dynamic (this=this@entry=0xa00030, dynp=<optimized out\>) at p\_lx\_elf.cpp:1688
1688                if (buckets\[j\]) {
\[ Legend: Modified register | Code | Heap | Stack | String \]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── registers ────
$rax   : 0x0000000000a009c1  →  0x00000000ffffffff
$rbx   : 0x0000000000a00030  →  0x00000000007267a0  →  <vtable+0> add BYTE PTR \[rax\], al
$rcx   : 0x0               
$rdx   : 0x0               
$rsp   : 0x00007fffffffcc10  →  0x0000000000a007c0  →  0xff0000010900457f
$rbp   : 0xffffff00        
$rsi   : 0x7d88            
$rdi   : 0x6               
$rip   : 0x0000000000527258  →  <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov r9d, DWORD PTR \[rax+rsi\*4+0x1c\]
$r8    : 0x0               
$r9    : 0x0               
$r10   : 0x10              
$r11   : 0x0               
$r12   : 0xd               
$r13   : 0xffffffff        
$r14   : 0x200             
$r15   : 0x0               
$eflags: \[carry PARITY adjust ZERO sign trap INTERRUPT direction overflow RESUME virtualx86 identification\]
$cs: 0x0033 $ss: 0x002b $ds: 0x0000 $es: 0x0000 $fs: 0x0000 $gs: 0x0000 
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
0x00007fffffffcc10│+0x0000: 0x0000000000a007c0  →  0xff0000010900457f     ← $rsp
0x00007fffffffcc18│+0x0008: 0x0000000000000000
0x00007fffffffcc20│+0x0010: 0x00007ffff7352260  →  <read+16> cmp rax, 0xfffffffffffff001
0x00007fffffffcc28│+0x0018: 0x0000000000000258
0x00007fffffffcc30│+0x0020: 0x00007ffff7362447  →  <lseek64+7> cmp rax, 0xfffffffffffff001
0x00007fffffffcc38│+0x0028: 0x00000000005255b2  →  <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov rax, QWORD PTR \[rsp+0x10\]
0x00007fffffffcc40│+0x0030: 0x0000000000000000
0x00007fffffffcc48│+0x0038: 0x0000000000000000
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:x86:64 ────
     0x527247 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    rcx, QWORD PTR \[rsp+0x8\]
     0x52724c <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    rdx, QWORD PTR \[rsp\]
     0x527250 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> lea    rsp, \[rsp+0x98\]
 →   0x527258 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    r9d, DWORD PTR \[rax+rsi\*4+0x1c\]
     0x52725d <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> test   r9d, r9d
     0x527260 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> je     0x5272eb <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,  LE32,  LE32,  LE32,  LE32> \> const\*)+7515>
     0x527266 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> xchg   ax, ax
     0x527268 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> lea    rsp, \[rsp-0x98\]
     0x527270 <PackLinuxElf32::invert\_pt\_dynamic(N\_Elf::Dyn<N\_Elf::ElfITypes<LE16,+0> mov    QWORD PTR \[rsp\], rdx
───────────────────────────────────────────────────────────────────────────────────────────────────────────────── source:p\_lx\_elf.cpp+1688 ────
   1683             unsigned     const \*const hasharr = &buckets\[n\_bucket\]; (void)hasharr;
   1684           //unsigned     const \*const gashend = &hasharr\[n\_bucket\];  // minimum, except:
   1685             // Rust and Android trim unused zeroes from high end of hasharr\[\]
   1686             unsigned bmax = 0;
   1687             for (unsigned j= 0; j < n\_bucket; ++j) {
 → 1688                 if (buckets\[j\]) {
   1689                     if (buckets\[j\] < symbias) {
   1690                         char msg\[50\]; snprintf(msg, sizeof(msg),
   1691                                 "bad DT\_GNU\_HASH bucket\[%d\] < symbias{%#x}\\n",
   1692                                 buckets\[j\], symbias);
   1693                         throwCantPack(msg);
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
\[#0\] Id 1, Name: "upx.out", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
\[#0\] 0x527258 → PackLinuxElf32::invert\_pt\_dynamic(this=0xa00030, dynp=<optimized out>)
\[#1\] 0x529294 → PackLinuxElf32::invert\_pt\_dynamic(dynp=<optimized out>, this=0xa00030)
\[#2\] 0x529294 → PackLinuxElf32::PackLinuxElf32help1(this=0xa00030, f=0x7fffffffce20)
\[#3\] 0x52c65e → PackLinuxElf32Le::PackLinuxElf32Le(f=0x7fffffffce20, this=0xa00030)
\[#4\] 0x52c65e → PackLinuxElf32x86::PackLinuxElf32x86(f=0x7fffffffce20, this=0xa00030)
\[#5\] 0x52c65e → PackBSDElf32x86::PackBSDElf32x86(f=0x7fffffffce20, this=0xa00030)
\[#6\] 0x52c65e → PackFreeBSDElf32x86::PackFreeBSDElf32x86(this=0xa00030, f=0x7fffffffce20)
\[#7\] 0x60448c → PackMaster::visitAllPackers(func=0x602c30 <try\_unpack(Packer\*, void\*)>, f=0x7fffffffce20, o=0x7fffffffcfd8, user=0x7fffffffce20)
\[#8\] 0x6072ca → PackMaster::getUnpacker(f=<optimized out>)
\[#9\] 0x6072ca → PackMaster::unpack(this=0x7fffffffcfc0, fo=0x7fffffffcef0)

The instruction to crash is, corresponds to the bucket \[j\] in the source code

mov    r9d, DWORD PTR \[rax+rsi\*4+0x1c\]

The value of register rax and rsi are:

$rax   : 0x0000000000a009c1
$rsi   : 0x7d88

The DWORD PTR pointer to 0xa1fffd, where the 0xa20000 is a invalid address.

gef➤  x /10xg 0xa1fffd
0xa1fffd:    Cannot access memory at address 0xa20000

**What should have happened?**

Decompress a crafted/suspicious file.

**Do you have an idea for a solution?**

A boundary check is needed for loop variable 'j' because the size allocated for variable 'buckets' is limited.

unsigned const \*const bitmask = (unsigned const \*)(void const \*)&gashtab\[4\];
unsigned     const \*const buckets = (unsigned const \*)&bitmask\[n\_bitmask\];
unsigned     const \*const hasharr = &buckets\[n\_bucket\]; (void)hasharr;
//unsigned     const \*const gashend = &hasharr\[n\_bucket\];  // minimum, except:
// Rust and Android trim unused zeroes from high end of hasharr\[\]
unsigned bmax = 0;
for (unsigned j= 0; j < n\_bucket; ++j) {
    if (buckets\[j\]) {

**How can we reproduce the issue?**

1.  compile upx with address-sanitize
2.  execute cmd

upx.out -df $PoC -o /dev/null

Poc can be found here.

**Please tell us details about your environment.**

*   UPX version used (upx --version):

upx 4.0.0-git-c6b9e3c62d15 (latest-devel-branch)
UCL data compression library 1.03
zlib data compression library 1.2.8
LZMA SDK version 4.43

*   Host Operating System and version:  
    Ubuntu 16.04 64-bit
*   Host CPU architecture:  
    Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz with 8GB
*   Target Operating System and version:  
    same as Host
*   Target CPU architecture:  
    same as Host

CVE-2021-43313: [bug]heap buffer overflow in PackLinuxElf32::invert_pt_dynamic at p_lx_elf.cpp:1688 · Issue #378 · upx/upx

A heap-based buffer overflow was discovered in upx, during the generic pointer 'p' points to an inaccessible address in func get_le64().

**What's the problem (or question)?**

A heap-based buffer overflow was discovered in upx, during the genric pointer 'p' points to an inaccessible address in func get\_le64(). The issue can cause a denial of service. The issue is diff from issue367 and issue368

ASAN reports:

ASAN:SIGSEGV
=================================================================
==113201==ERROR: AddressSanitizer: SEGV on unknown address 0x630011d04b20 (pc 0x0000005292e0 bp 0x000000000022 sp 0x7ffebc640bc8 T0)
    #0 0x5292df in get\_le64(void const\*) /home/test/Desktop/EVAULATION/upx/src/bele\_policy.h:193
    #1 0x5292df in N\_BELE\_RTP::LEPolicy::get64(void const\*) const /home/test/Desktop/EVAULATION/upx/src/bele\_policy.h:194
    #2 0x45784b in Packer::get\_te64(void const\*) const /home/test/Desktop/EVAULATION/upx/src/packer.h:297
    #3 0x45784b in PackLinuxElf64::elf\_lookup(char const\*) const /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:5423
    #4 0x46f7eb in PackLinuxElf64::PackLinuxElf64help1(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:805
    #5 0x470479 in PackLinuxElf64Le::PackLinuxElf64Le(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.h:407
    #6 0x470479 in PackLinuxElf64amd::PackLinuxElf64amd(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/p\_lx\_elf.cpp:1008
    #7 0x4f34b2 in PackMaster::visitAllPackers(Packer\* (\*)(Packer\*, void\*), InputFile\*, options\_t const\*, void\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:194
    #8 0x4f50f9 in PackMaster::getUnpacker(InputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:248
    #9 0x4f521f in PackMaster::unpack(OutputFile\*) /home/test/Desktop/EVAULATION/upx/src/packmast.cpp:266
    #10 0x52a1e6 in do\_one\_file(char const\*, char\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:160
    #11 0x52a69e in do\_files(int, int, char\*\*) /home/test/Desktop/EVAULATION/upx/src/work.cpp:271
    #12 0x403ace in main /home/test/Desktop/EVAULATION/upx/src/main.cpp:1538
    #13 0x7fc4129b682f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2082f)
    #14 0x404828 in \_start (/home/test/Desktop/EVAULATION/upx/src/upx.out+0x404828)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/test/Desktop/EVAULATION/upx/src/bele\_policy.h:193 get\_le64(void const\*)
==113201==ABORTING

The essential cause of the bug is at PackLinuxElf64 :: elf\_lookup () at p\_lx\_elf: 5423:

upx\_uint64\_t const w = get\_te64(&bitmask\[(n\_bitmask -1) & (h>>6)\]);

**What should have happened?**

Decompress a crafted/suspicious file.

**Do you have an idea for a solution?**

We are very grateful to @jreiser for patching the bucket in p\_lx\_elf.cpp in the issue 367. However, in fact, all places involving get\_te64 () should be strengthened in upx, especially in p\_lx\_elf.cpp. The position we reported should be patched at least:  
position in PackLinuxElf64::elf\_lookup() at p\_lx\_elf:5423

upx\_uint64\_t const w = get\_te64(&bitmask\[(n\_bitmask -1) & (h>>6)\]);

**How can we reproduce the issue?**

1.  compile upx with address-sanitize
2.  execute cmd

upx.out -df $PoC -o /dev/null

Poc can be found here.

**Please tell us details about your environment.**

*   UPX version used (upx --version):

upx 4.0.0-git-c6b9e3c62d15 (latest-devel-branch)
UCL data compression library 1.03
zlib data compression library 1.2.8
LZMA SDK version 4.43

*   Host Operating System and version:  
    Ubuntu 16.04 64-bit
*   Host CPU architecture:  
    Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz with 8GB
*   Target Operating System and version:  
    same as Host
*   Target CPU architecture:  
    same as Host

CVE-2021-43316: [bug] segv fault in get_le64() · Issue #381 · upx/upx

The second malicious ChatGPT extension for Chrome has been discovered, giving malicious actors access to users' Facebook accounts through stolen cookies.

Yet another version of the malicious, Facebook account-stealing ChatGPT browser extension for Google Chrome has emerged, representing a new variant in a campaign affecting thousands of users daily.

The extension, discovered by Guardio Labs, was downloaded more than 9,000 times before Google removed it from the Chrome store on March 22.

The extension also had been advertised through sponsored Google search results, aiming at users who were searching for details about OpenAI's latest Chat GPT4 algorithm. Individuals who clicked on sponsored results for the popular generative AI app were directed to a counterfeit "ChatGPT for Google" webpage, then led to the malicious extension's page on Chrome's official store.

Once installed, the malware exploits the Chrome Extension API to pilfer session cookies for Facebook accounts, giving threat actors full access to a victim's Facebook account.

"Based on version 1.16.6 of the open source project, this FakeGPT variant does only one specific malicious action, right after installation, and the rest is basically the same as the genuine code — leaving no reasons to suspect it," Nati Tal, head of Guardio Labs, wrote in a blog post.

The latest version of the malicious extension follows one discovered earlier this month by the researchers at Guardio, which could hijack Facebook Business accounts.

From March 3 to March 9, a minimum of 2,000 individuals per day acquired that malicious "Quick access to ChatGPT" Chrome extension from the Google Play app store.

If the extension was able to access a Facebook Business account, it immediately collected all relevant data related to that account, such as ongoing promotions, available credit, currency, minimum billing threshold, and any linked credit facility.

**Malicious Chrome Extensions a Growing Threat**

Malicious Chrome extensions have been a global concern for users of the popular browser. In August 2022, a group of McAfee Labs analysts published a list of five browser extensions that engage in cookie stuffing, one of them using the video streaming service Netflix as a hook.

These extensions monitor the browsing activity of the user and insert illegitimate IDs into e-commerce websites, resulting in fabricated affiliate payments.

In that case, the applications were downloaded 1.4 million times, according to their findings.

In November 2022, researchers at Zimperium zLabs uncovered a "Swiss Army knife-like" malicious browser extension called Cloud9, aimed at Chrome and Microsoft Edge users. It enables attackers to seize control of a user's browser session remotely and execute a broad range of attacks.

The Zimperium report noted that because the Cloud9 malware does not target any specific group, it is as much an enterprise threat as it is a consumer threat.

**Kimsuky North Korean Threat Actors Target Chrome**

More recently, the German Federal Office for the Protection of the Constitution (BfV) and the South Korean intelligence service (NIS) issued a warning of a cyber-espionage group that is said to target government agencies and research organizations worldwide.

The Kimsuky group of cybercriminals, aka Velvet Chollima or Thallium, is thought to be based in North Korea and uses malicious Chrome browser extensions as well as app store services to target individuals conducting research on the inter-Korean conflict.

The hackers use so-called spear-phishing attacks. In these, targets are lured by emails to fake versions of well-known websites disguised as legitimate or tricked into installing a manipulated browser extension.

In the process, login data and other personal information could be intercepted by the attackers. Another method used by the hackers is to install malware unnoticed on Android smartphones via the Google Play app store.

Malicious ChatGPT Extensions Add to Google Chrome Woes

An issue was discovered in the Linux kernel before 5.8. lib/nlattr.c allows attackers to cause a denial of service (unbounded recursion) via a nested Netlink policy with a back reference.

Permalink

Browse files

netlink: limit recursion depth in policy validation

Now that we have nested policies, we can theoretically
recurse forever parsing attributes if a (sub-)policy
refers back to a higher level one. This is a situation
that has happened in nl80211, and we've avoided it there
by not linking it.

Add some code to netlink parsing to limit recursion depth.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

*   Loading branch information

CVE-2020-36691: netlink: limit recursion depth in policy validation · torvalds/linux@7690aa1

A contrarian mindset with applied imagination allows security professionals to assess problems in their organizations, prevent failures, and mitigate vulnerabilities.

During the global war on terror, a group of commissioned and noncommissioned officers in the United States military participated in a unique training event. Soldiers of various ranks, all with different specialties, assembled in a remote location where they were stripped of rank and other identifying markers. They changed clothes, adopted new names, and modified the very rhythm of their daily lives. And from there, they began planning a simulated attack on their own forces.

The exercise, an ongoing training opportunity called "Mirror Image" being conducted by the Terrorism Research Center, is part of a greater philosophy called red teaming. The simulation helped participants explore their predispositions and organizational weaknesses. Changing routines helped them better understand enemy motivations and anticipate possible insurgent attacks. It also revealed how biases and expectations interfered with reality.

In the business world, cybersecurity professionals use red teaming to test their organizations' defenses before something happens. But other groups can utilize the concept to test resilience, blind spots, and continuity in the face of a crisis.

Organizations should conduct red-teaming exercises at scale to manage risk holistically. The idea is to understand potential outcomes based on multiple strategic options, utilizing scenarios to identify blind spots and model threats to eliminate weaknesses before adversaries exploit them. It is a valuable tool in both policy and decision-making.

**Make the Most of Your Red-Teaming Exercise**

Here are some actions to take to ensure your organization gets the most out of red teaming:

**Ask where the enemy is going.** An effective red-team exercise reveals exploits in your security systems and processes. The entire point is to find failures. This isn't always easy for professionals to accept and encourage. Foster an environment of openness that allows teams to explore threats and how they'll try to overcome defenses in place. Ultimately, red teaming provides growth opportunities that improve threat response when the time comes.

**Evaluate the response, not just the defense.** Red teaming is more than a penetration test. Knowing where your gaps are is crucial, but knowing how your team reacts to a crisis is far more valuable. While defense, mitigation, and deterrence are essential, sometimes defenses fail or plans go awry. It's useful to model a scenario where your defenses or mitigation strategies fail, so your company can react and prepare for something similar in real life.

**Model information flow.** Critical information doesn't always get to the right people in a crisis. According to a recent survey, 51% of threats that disrupted business continuity or resulted in harm or death in 2022 could have been avoided if all functions shared risk intelligence and viewed it with a common approach and platform.

**Test your assumptions.** Many defensive measures are built on a set of assumptions about risk and their likelihood. However, our study reveals disagreement within companies and departments over which events threaten business continuity. Security gaps are more likely to occur when teams aren't on the same page. In such situations, people overlook problems or assume someone else will handle an issue. Red teaming clears up questions around responsibility and how to weigh risks.

**Test your processes.** Red teaming can be used to test physical defenses and cybersecurity, but it is also a useful tool to assess processes. In security, an overly complicated or ill-defined process can be just as harmful as inadequate barriers or cameras. Tabletop exercises or war games force organizations through their processes to see how well they work.

**Explore alternative futures.** Structural analytic techniques help business organizations and security professionals apply imagination to forecast alternative futures for their decisions. This kind of exercise is not about prognostication but expanding one's critical mindset to understand the many variables that impact the organization and possibilities for the future. This red-team approach offers organizations insight used for decision-making by recognizing the complexity of choices and their impacts on the company or security.

**Adopt a Holistic Viewpoint**

The concept of red teaming is based on the Catholic Church office of the devil's advocate, but it was greatly expanded to assess Soviet intentions and capabilities. That's where it got its name: The US adversary during the Cold War was the Soviet Union, aka the Reds. Recently, cybersecurity teams adopted red teaming to expose weaknesses in their systems and prevent threat exposure.

The fact is that enterprises face a wide variety of threats — from lawsuits, activists, insider threats, and even workplace violence. Yet nearly every Google search result for red teaming today relates to cybersecurity. As a result, few people know whether their crisis plans are up to date or how a crisis will test them and their teams.

Red teaming is a holistic, multidisciplinary effort that arms teams with practical enterprise risk-mitigation software and other tools across the entire threat landscape. At a minimum, risk-focused teams can use it to test defenses against a wide range of threat actors and identify unseen security gaps influenced by biases and assumptions.

However, its actual value is how it shapes the ways organizations prepare for crises and unforeseen events. Red teaming opens a window to how your organization will perform under duress, making it a valuable exercise to recognize and gauge real and potential risks.

Most importantly, red teaming is a mindset, not just a set of tools or putting security on offense. Red teams are the contrarians in the room, willingly saying what other people will not to challenge the status quo. That is the essence of red teaming, and any security professional can adopt that attitude to assess problems in their organization, prevent failure, or mitigate vulnerabilities. The mindset of a red teamer is what shapes organizations for the better.

Tag

#intel