ATasm 1.06 has a stack-based buffer overflow in the to_comma() function in asm.c via a crafted .m65 file.

*   Summary
*   Files
*   Reviews
*   Support
*   Wiki
*   Tickets ▾
    *   Bugs
    *   Feature Requests
*   News
*   Code
*   Discussion

Menu ▾ ▴

**#8 Stack-based buffer overflow in the to\_comma() function**

Status: closed

Owner: nobody

Labels: None

Priority: 5

Updated: 2021-03-20

Created: 2019-12-13

Private: No

Hi,

While fuzzing ATasm 1.08 with Honggfuzz, I found a stack-based buffer overflow in the to\_comma() function, in asm.c.

Attaching a reproducer, issue can be reproduced by running:

\=================================================================
\==15033\==ERROR: AddressSanitizer: stack\-buffer\-overflow on address 0x7ffec9190ef0 at pc 0x0000004ce38e bp 0x7ffec9190e30 sp 0x7ffec9190e28
WRITE of size 1 at 0x7ffec9190ef0 thread T0
    #0 0x4ce38d in to\_comma /home/fcambus/atasm/src/asm.c:1126:11
    #1 0x4ce38d in do\_xbyte /home/fcambus/atasm/src/asm.c:1346:9
    #2 0x4cfe17 in proc\_sym /home/fcambus/atasm/src/asm.c:1553:7
    #3 0x4d5556 in do\_cmd /home/fcambus/atasm/src/asm.c:1941:5
    #4 0x4d5b46 in assemble /home/fcambus/atasm/src/asm.c:1980:9
    #5 0x4d8082 in main /home/fcambus/atasm/src/asm.c:2392:3
    #6 0x7f32f46441e2 in \_\_libc\_start\_main /build/glibc\-4WA41p/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #7 0x41b3fd in \_start (/home/fcambus/atasm/atasm+0x41b3fd)

Address 0x7ffec9190ef0 is located in stack of thread T0 at offset 176 in frame
    #0 0x4cc7af in do\_xbyte /home/fcambus/atasm/src/asm.c:1299

  This frame has 2 object(s):
    \[32, 64) 'buf.i' (line 736)
    \[96, 176) 'buf' (line 1301) <== Memory access at offset 176 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack\-buffer\-overflow /home/fcambus/atasm/src/asm.c:1126:11 in to\_comma
Shadow bytes around the buggy address:
  0x10005922a180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a1a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a1c0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8
\=>0x10005922a1d0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00\[f3\]f3
  0x10005922a1e0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005922a200: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8
  0x10005922a210: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10005922a220: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2
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
\==15033\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2019-19785: ATasm: 6502 cross-assembler / Bugs

ATasm 1.06 has a stack-based buffer overflow in the parse_expr() function in setparse.c via a crafted .m65 file.

*   Summary
*   Files
*   Reviews
*   Support
*   Wiki
*   Tickets ▾
    *   Bugs
    *   Feature Requests
*   News
*   Code
*   Discussion

Menu ▾ ▴

**#9 Stack-based buffer overflow in the parse\_expr() function**

Status: closed

Owner: nobody

Labels: None

Priority: 5

Updated: 2021-03-20

Created: 2019-12-13

Private: No

Hi,

While fuzzing ATasm 1.08 with Honggfuzz, I found a stack-based buffer overflow in the parse\_expr() function, in setparse.c.

Attaching a reproducer, issue can be reproduced by running:

\=================================================================
\==29838\==ERROR: AddressSanitizer: stack\-buffer\-overflow on address 0x7fff079a8b00 at pc 0x0000004e0478 bp 0x7fff079a8a70 sp 0x7fff079a8a68
WRITE of size 1 at 0x7fff079a8b00 thread T0
    #0 0x4e0477 in parse\_expr /home/fcambus/atasm/src/setparse.c:83:13
    #1 0x4e236d in get\_signed\_expression /home/fcambus/atasm/src/setparse.c:319:5
    #2 0x4e08a5 in get\_expression /home/fcambus/atasm/src/setparse.c:154:27
    #3 0x4d3deb in proc\_sym /home/fcambus/atasm/src/asm.c:1678:14
    #4 0x4d5556 in do\_cmd /home/fcambus/atasm/src/asm.c:1941:5
    #5 0x4d5b46 in assemble /home/fcambus/atasm/src/asm.c:1980:9
    #6 0x4d8082 in main /home/fcambus/atasm/src/asm.c:2392:3
    #7 0x7fad7a5101e2 in \_\_libc\_start\_main /build/glibc\-4WA41p/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #8 0x41b3fd in \_start (/home/fcambus/atasm/atasm+0x41b3fd)

Address 0x7fff079a8b00 is located in stack of thread T0 at offset 128 in frame
    #0 0x4dfd9f in parse\_expr /home/fcambus/atasm/src/setparse.c:71

  This frame has 2 object(s):
    \[32, 36) 'v' (line 72)
    \[48, 128) 'expr' (line 73) <== Memory access at offset 128 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack\-buffer\-overflow /home/fcambus/atasm/src/setparse.c:83:13 in parse\_expr
Shadow bytes around the buggy address:
  0x100060f2d110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d150: f1 f1 f1 f1 04 f2 00 00 00 00 00 00 00 00 00 00
\=>0x100060f2d160:\[f3\]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d170: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8
  0x100060f2d180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x100060f2d190: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2
  0x100060f2d1a0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
  0x100060f2d1b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
\==29838\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2019-19786: ATasm: 6502 cross-assembler / Bugs

ATasm 1.06 has a stack-based buffer overflow in the get_signed_expression() function in setparse.c via a crafted .m65 file.

*   Summary
*   Files
*   Reviews
*   Support
*   Wiki
*   Tickets ▾
    *   Bugs
    *   Feature Requests
*   News
*   Code
*   Discussion

Menu ▾ ▴

**#10 Stack-based buffer overflow in the get\_signed\_expression() function**

Status: closed

Owner: nobody

Labels: None

Priority: 5

Updated: 2021-03-20

Created: 2019-12-13

Private: No

Hi,

While fuzzing ATasm 1.08 with Honggfuzz, I found a stack-based buffer overflow in the get\_signed\_expression() function, in setparse.c.

Attaching a reproducer, issue can be reproduced by running:

\=================================================================
\==10633\==ERROR: AddressSanitizer: stack\-buffer\-overflow on address 0x7ffe5c1b3480 at pc 0x0000004e27ea bp 0x7ffe5c1b3210 sp 0x7ffe5c1b3208
WRITE of size 1 at 0x7ffe5c1b3480 thread T0
    #0 0x4e27e9 in get\_signed\_expression /home/fcambus/atasm/src/setparse.c:179:14
    #1 0x4e08a5 in get\_expression /home/fcambus/atasm/src/setparse.c:154:27
    #2 0x4c8de1 in add\_label /home/fcambus/atasm/src/asm.c
    #3 0x4d5563 in do\_cmd /home/fcambus/atasm/src/asm.c:1934:5
    #4 0x4d5b46 in assemble /home/fcambus/atasm/src/asm.c:1980:9
    #5 0x4d8082 in main /home/fcambus/atasm/src/asm.c:2392:3
    #6 0x7f1cbb2811e2 in \_\_libc\_start\_main /build/glibc\-4WA41p/glibc\-2.30/csu/../csu/libc\-start.c:308:16
    #7 0x41b3fd in \_start (/home/fcambus/atasm/atasm+0x41b3fd)

Address 0x7ffe5c1b3480 is located in stack of thread T0 at offset 608 in frame
    #0 0x4e08bf in get\_signed\_expression /home/fcambus/atasm/src/setparse.c:157

  This frame has 4 object(s):
    \[32, 288) 'err.i' (line 136)
    \[352, 608) 'buf' (line 158) <== Memory access at offset 608 overflows this variable
    \[672, 928) 'work' (line 158)
    \[992, 1005) 'math' (line 162)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions \*are\* supported)
SUMMARY: AddressSanitizer: stack\-buffer\-overflow /home/fcambus/atasm/src/setparse.c:179:14 in get\_signed\_expression
Shadow bytes around the buggy address:
  0x10004b82e640: 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8
  0x10004b82e650: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  0x10004b82e660: f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2 f2 f2 f2
  0x10004b82e670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004b82e680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x10004b82e690:\[f2\]f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
  0x10004b82e6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004b82e6b0: 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 f2 f2
  0x10004b82e6c0: 00 05 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004b82e6d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004b82e6e0: 00 00 00 00 f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8
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
\==10633\==ABORTING

**1 Attachments**

**Discussion**

Log in to post a comment.

CVE-2019-19787: ATasm: 6502 cross-assembler / Bugs

OpenBSD through 6.6 allows local users to escalate to root because a check for LD_LIBRARY_PATH in setuid programs can be defeated by setting a very small RLIMIT_DATA resource limit. When executing chpass or passwd (which are setuid root), _dl_setup_env in ld.so tries to strip LD_LIBRARY_PATH from the environment, but fails when it cannot allocate memory. Thus, the attacker is able to execute their own library code as root.

For errata on a certain release, click below:  
2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5,  
3.6, 3.7, 3.8, 3.9, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 5.0, 5.1,  
5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 6.7, 6.8,  
6.9, 7.0, 7.1, 7.2.

Patches for the OpenBSD base system are distributed as unified diffs. Each patch is cryptographically signed with the signify(1) tool and contains usage instructions. All the following patches are also available in one tar.gz file for convenience.

Alternatively, the syspatch(8) utility can be used to apply binary updates on the following architectures: amd64, i386, arm64.

Patches for supported releases are also incorporated into the \-stable branch.

*   **001: RELIABILITY FIX: October 28, 2019**   _All architectures_  
    bpf(4) has a race condition during device removal.  
    A source code patch exists which remedies this problem.
*   **002: RELIABILITY FIX: October 28, 2019**   _All architectures_  
    Various third party applications may crash due to symbol collision.  
    A source code patch exists which remedies this problem.
*   **003: RELIABILITY FIX: October 31, 2019**   _All architectures_  
    bgpd(8) can crash on nexthop changes or during startup in certain configurations.  
    A source code patch exists which remedies this problem.
*   **004: RELIABILITY FIX: November 16, 2019**   _All architectures_  
    The kernel could crash due to a NULL pointer dereference in net80211.  
    A source code patch exists which remedies this problem.
*   **005: RELIABILITY FIX: November 16, 2019**   _All architectures_  
    A new kernel may require newer firmware images when using sysupgrade.  
    A source code patch exists which remedies this problem.
*   **006: SECURITY FIX: November 16, 2019**   _All architectures_  
    A regular user could change some network interface parameters due to missing checks in the ioctl(2) system call.  
    A source code patch exists which remedies this problem.
*   **007: SECURITY FIX: November 22, 2019**   _i386 and amd64_  
    A local user could cause the system to hang by reading specific registers when Intel Gen8/Gen9 graphics hardware is in a low power state. A local user could perform writes to memory that should be blocked with Intel Gen9 graphics hardware.  
    A source code patch exists which remedies this problem.
*   **008: SECURITY FIX: November 22, 2019**   _All architectures_  
    Shared memory regions used by some Mesa drivers had permissions which allowed others to access that memory.  
    A source code patch exists which remedies this problem.
*   **009: SECURITY FIX: December 4, 2019**   _All architectures_  
    Environment-provided paths are used for dlopen() in mesa, resulting in escalation to the auth group in xlock(1).  
    A source code patch exists which remedies this problem.
*   **010: SECURITY FIX: December 4, 2019**   _All architectures_  
    libc's authentication layer performed insufficient username validation.  
    A source code patch exists which remedies this problem.
*   **011: SECURITY FIX: December 4, 2019**   _All architectures_  
    xenodm uses the libc authentication layer incorrectly.  
    A source code patch exists which remedies this problem.
*   **012: SECURITY FIX: December 8, 2019**   _All architectures_  
    A user can log in with a different user's login class.  
    A source code patch exists which remedies this problem.
*   **013: SECURITY FIX: December 11, 2019**   _All architectures_  
    ld.so may fail to remove the LD\_LIBRARY\_PATH environment variable for set-user-ID and set-group-ID executables in low memory conditions.  
    A source code patch exists which remedies this problem.
*   **014: SECURITY FIX: December 18, 2019**   _arm64_  
    ARM64 CPUs speculatively execute instructions after ERET.  
    A source code patch exists which remedies this problem.
*   **015: SECURITY FIX: December 20, 2019**   _All architectures_  
    ftp(1) will follow remote redirects to local files.  
    A source code patch exists which remedies this problem.
*   **016: SECURITY FIX: December 20, 2019**   _All architectures_  
    ripd(8) fails to validate authentication lengths.  
    A source code patch exists which remedies this problem.
*   **017: SECURITY FIX: January 17, 2020**   _i386 and amd64_  
    Execution Unit state was not cleared on context switch with Intel Gen9 graphics hardware.  
    A source code patch exists which remedies this problem.
*   **018: RELIABILITY FIX: January 30, 2020**   _All architectures_  
    smtpd can crash on opportunistic TLS downgrade, causing a denial of service.  
    A source code patch exists which remedies this problem.
*   **019: SECURITY FIX: January 30, 2020**   _All architectures_  
    An incorrect check allows an attacker to trick mbox delivery into executing arbitrary commands as root and lmtp delivery into executing arbitrary commands as an unprivileged user.  
    A source code patch exists which remedies this problem.
*   **020: SECURITY FIX: February 17, 2020**   _amd64_  
    A missing range check in the vmm pvclock allows a guest to write to host memory.  
    A source code patch exists which remedies this problem.
*   **021: SECURITY FIX: February 24, 2020**   _All architectures_  
    An out of bounds read in smtpd allows an attacker to inject arbitrary commands into the envelope file which are then executed as root. Separately, missing privilege revocation in smtpctl allows arbitrary commands to be run with the \_smtpq group.  
    A source code patch exists which remedies this problem.
*   **022: RELIABILITY FIX: March 10, 2020**   _All architectures_  
    Missing input validation in sysctl(2) can be used to crash the kernel.  
    A source code patch exists which remedies this problem.
*   **023: RELIABILITY FIX: March 13, 2020**   _All architectures_  
    Local outbound UDP broadcast or multicast packets sent by a spliced socket can crash the kernel.  
    A source code patch exists which remedies this problem.
*   **024: SECURITY FIX: April 7, 2020**   _All architectures_  
    dhcpd could reference freed memory after releasing a lease with an unusually long uid.  
    A source code patch exists which remedies this problem.
*   **025: SECURITY FIX: April 19, 2020**   _i386, amd64, arm64, loongson, macppc, sparc64_  
    There was an incorrect test for root in the DRM Linux compatibility code.  
    A source code patch exists which remedies this problem.
*   **026: RELIABILITY FIX: May 10, 2020**   _All architectures_  
    ospfd could generate corrupt OSPF Router (Type 1) LSAs in certain situations.  
    A source code patch exists which remedies this problem.
*   **027: SECURITY FIX: May 13, 2020**   _All architectures_  
    An out-of-bounds index access in wscons(4) can cause a kernel crash.  
    A source code patch exists which remedies this problem.
*   **028: SECURITY FIX: May 22, 2020**   _All architectures_  
    Specially crafted queries may crash unbound and unwind. Both can be tricked into amplifying an incoming query.  
    A source code patch exists which remedies this problem.
*   **029: SECURITY FIX: June 1, 2020**   _All architectures_  
    Several problems in Perl's regular expression compiler could lead to corruption of the intermediate language state of a compiled regular expression.  
    A source code patch exists which remedies this problem.
*   **030: SECURITY FIX: June 5, 2020**   _All architectures_  
    Malicious HID descriptors could be misparsed.  
    A source code patch exists which remedies this problem.
*   **031: RELIABILITY FIX: June 8, 2020**   _All architectures_  
    libc's resolver could get into a corrupted state.  
    A source code patch exists which remedies this problem.
*   **032: RELIABILITY FIX: June 11, 2020**   _All architectures_  
    libcrypto may fail to build a valid certificate chain due to expired untrusted issuer certificates.  
    A source code patch exists which remedies this problem.
*   **033: SECURITY FIX: July 9, 2020**   _All architectures_  
    shmget IPC\_STAT leaked some kernel data.  
    A source code patch exists which remedies this problem.
*   **034: RELIABILITY FIX: July 16, 2020**   _All architectures_  
    tty subsystem abuse can impact performance badly.  
    A source code patch exists which remedies this problem.
*   **035: RELIABILITY FIX: July 22, 2020**   _All architectures_  
    Only pty devices need reprint delays.  
    A source code patch exists which remedies this problem.
*   **036: SECURITY FIX: July 27, 2020**   _All architectures_  
    In iked, incorrect use of EVP\_PKEY\_cmp allows an authentication bypass.  
    A source code patch exists which remedies this problem.
*   **037: SECURITY FIX: July 31, 2020**   _All architectures_  
    Malformed messages can cause heap corruption in the X Input Method client implementation in libX11.  
    A source code patch exists which remedies this problem.
*   **038: SECURITY FIX: July 31, 2020**   _All architectures_  
    Pixmaps inside the xserver were an info leak.  
    A source code patch exists which remedies this problem.
*   **039: RELIABILITY FIX: August 7, 2020**   _All architectures_  
    The recent security errata 037 broke X11 input methods.  
    A source code patch exists which remedies this problem.
*   **040: SECURITY FIX: August 25, 2020**   _All architectures_  
    An integer overflow in libX11 could lead to a double free. Additionally fix a regression in ximcp.  
    A source code patch exists which remedies this problem.
*   **041: SECURITY FIX: August 25, 2020**   _All architectures_  
    Various X server extensions had deficient input validation.  
    A source code patch exists which remedies this problem.
*   **042: SECURITY FIX: September 5, 2020**   _amd64, arm64_  
    A buffer overflow was discovered in an amdgpu ioctl.  
    A source code patch exists which remedies this problem.

CVE-2019-19726: OpenBSD 6.6 Errata

An exploitable heap out of bounds write vulnerability exists in the UI tag parsing functionality of the DICOM image format of LEADTOOLS 20.0.2019.3.15. A specially crafted DICOM image can cause an offset beyond the bounds of a heap allocation to be written, potentially resulting in code execution. An attacker can specially craft a DICOM image to trigger this vulnerability.

**Summary**

An exploitable heap out of bounds write vulnerability exists in the UI tag parsing functionality of the DICOM image format of LEADTOOLS 20. A specially crafted DICOM image can cause an offset beyond the bounds of a heap allocation to be written, potentially resulting in code execution. An attacker can specially craft a DICOM image to trigger this vulnerability.

**Tested Versions**

LEADTOOLS 20.0.2019.3.15

**Product URLs**

https://www.leadtools.com/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-787 - Out-of-bounds Write

**Details**

LEADTOOLS, according to the website, “is a collection of comprehensive toolkits to integrate document, medical, multimedia, and imaging technologies into desktop, server, tablet, and mobile applications”. It offers prebuilt and portable libraries with an SDK for most platforms (Windows, Linux, Android, etc), that are all geared towards building applications for medical systems.

The module analyzed in this vulnerability is below:

    Loaded symbol image file: C:\LEADTOOLS 20\Bin\CDLL\x64\ltdicx.dll
    Image path: C:\LEADTOOLS 20\Bin\CDLL\x64\ltdicx.dll
    Image name: ltdicx.dll
    Browse all global symbols  functions  data
    Timestamp:        Fri Mar  1 14:52:51 2019 (5C799BA3)
    CheckSum:         0017C012
    ImageSize:        00179000
    File version:     20.0.0.41
    Product version:  20.0.0.0
    

One toolkit provided by LEADTOOLS is a DICOM image parser. LEADTOOLS has a variety of prebuilt applications that leverage the DICOM library, including a direct image viewer and several DICOM servers.

Data in the DICOM format is formatted in a series of data structures. These data structures have various value representations (VR). Each VR describes the data type and format for that particular Data Element’s value. The UI tag (0x5549) includes a size field as well as the data immediately afterwards. An allocation occurs based on the size of the UI element.

    ltdicx+4db48
    .text:04DB48 8D 4D 01                lea     ecx, [rbp+1]    ; rcx - Size of UI element
    .text:04DB4B FF 15 77 8A 11 00       call    L_LocalAlloc    ; 
    

After the buffer is allocated, during the handling of the UI tag, there is a check if a backslash (‘') exists in the data buffer. If there is a backslash, it is replaced with a null in order to find the length of the substring ending in the backslash. The backslash is then replaced in order to calculate the length of the full data buffer by looking for an ending null byte.

    ltdicx+4e3b0
    .text:04E3B0  mov     edx, '\'        
    .text:04E3B5  mov     rcx, rsi           ; Data buffer
    .text:04E3B8  call    strchr             ; Find '\' in the data buffer
    .text:04E3BD  mov     rdi, rax
    .text:04E3C0  test    rax, rax
    .text:04E3C3  jz      short loc_4E3C8
    .text:04E3C5  mov     byte ptr [rax], 0  ; Replace '\' with a null
    .text:04E3C8  mov     rdx, rsi        
    .text:04E3CB  mov     rcx, r13        
    .text:04E3CE  call    LDicomDS::DelSpaces ; Delete any spaces in the data buffer 
    .text:04E3D3  test    rdi, rdi
    .text:04E3D6  jz      short loc_4E40C
    .text:04E3D8  mov     byte ptr [rdi], '\' ; Return data buffer to original state
    .text:04E3DB  mov     rax, rbp
    .text:04E3DE  inc     rdi
    .text:04E3E1  cmp     byte ptr [rdi+rax+1], 0 ; Find the length of the substring after '\'
    .text:04E3E6  lea     rax, [rax+1]
    .text:04E3EA  jnz     short loc_4E3E1
    .text:04E3EC  lea     r8d, [rax+1]            ; [0]
    .text:04E3F0  mov     rax, rbp
    .text:04E3F3  cmp     byte ptr [rsi+rax+1], 0 ; Find the length of the data buffer
    .text:04E3F8  lea     rax, [rax+1]
    

With the length of the data buffer and the length of the substring calculated, memmove is called to copy the second substring into the data buffer itself. The size of memmove is calculated and stored above \[0\].

    ltdicx+4ed401
    .text:04E401                 mov     rdx, rdi        ; Second substring
    .text:04E404                 add     rcx, rsi        ; Offset into the data buffer
    .text:04E407                 call    memmove
    

It is possible for an attacker to allocate a small enough buffer to hold the data after the memmove. The memmove will write data outside the bounds of the heap allocation, causing a heap based buffer overflow, potentially resulting in code execution.

**Crash Information**

    ltdicx!L_DicomChannelDeleteAnnotation+0x83b9:
    00007ffd`30260b19 0f1101          movups  xmmword ptr [rcx],xmm0 ds:00000272`d71e9ffb=????????????????????????????????
    
    >>> analyze -v
    MODULE_NAME: ltdicx
    IMAGE_NAME:  ltdicx.dll
    DEBUG_FLR_IMAGE_TIMESTAMP:  5c799ba3
    FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_AVRF_c0000005_ltdicx.dll!L_DicomChannelDeleteAnnotation
    BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_WRITE_AVRF_ltdicx!L_DicomChannelDeleteAnnotation+83b9
    FAILURE_EXCEPTION_CODE:  c0000005
    

**Timeline**

2019-08-08 - Vendor Disclosure  
2019-09-06 - 30 day follow up with vendor re: case number assigned  
2019-09-09 - Vendor acknowledged issue under review  
2019-10-21 - 60+ day follow up  
2019-12-05 - Vendor patched  
2019-12-10 - Public Release

Discovered by Marcin Towalski and Cory Duplantis of Cisco Talos.

CVE-2019-5092: TALOS-2019-0884 || Cisco Talos Intelligence Group

An exploitable heap overflow vulnerability exists in the JPEG2000 parsing functionality of LEADTOOLS 20.0.2019.3.15. A specially crafted J2K image file can cause an out of bounds write of a null byte in a heap buffer, potentially resulting in code execution. An attack can specially craft a J2K image to trigger this vulnerability.

**Summary**

An exploitable heap overflow vulnerability exists in the JPEG2000 parsing functionality of LEADTOOLS 20.0.2019.3.15. A specially crafted J2K image file can cause an out of bounds write of a null byte in a heap buffer, potentially resulting in code execution. An attack can specially craft a J2K image to trigger this vulnerability.

**Tested Versions**

LEADTOOLS 20.0.2019.3.15

**Product URLs**

https://www.leadtools.com/

**CVSSv3 Score**

8.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-122: Heap-based Buffer Overflow

**Details**

LEADTOOLS, according to the website, “is a collection of comprehensive toolkits to integrate document, medical, multimedia, and imaging technologies into desktop, server, tablet, and mobile applications”. It offers prebuilt and portable libraries with an SDK for most platforms (Windows, Linux, Android, etc), that are all geared towards building applications for medical systems.

The module used for this analysis is below: Mapped memory image file: C:\\LEADTOOLS 20\\Bin\\CDLL\\win32\\lfJ2kU.DLL Image path: C:\\LEADTOOLS 20\\Bin\\CDLL\\win32\\lfJ2kU.DLL Image name: lfJ2kU.DLL Browse all global symbols functions data Timestamp: Fri Mar 1 07:35:20 2019 (5C795138) CheckSum: 00058242 ImageSize: 0005D000 File version: 20.0.0.4 Product version: 20.0.0.0 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04e4

The JPEG2000 file format contains a number of different headers for various parts of the image. The jp2c header is used for designating a continuous codestream. This codestream has its own set of markers for storing the information in the codestream. The marker containing an image and tile size is 0xFF51. A description of the structure of this marker is below:

    Parameter Size (bits) Values
    SIZ       16          0xFF51
    Lsiz      16          4-49 191
    Rsiz      16          NA
    Xsiz      32          1 - (23**2 - 1)
    Ysiz      32          1 - (23**2 - 1)
    XOsiz     32          0 - (23**2 - 2)
    YOsiz     32          0 - (23**2 - 2)
    XTsiz     32          1 - (23**2 - 1)
    YTsiz     32          1 - (23**2 - 1)
    XTOsiz    32          0 - (23**2 - 2)
    YTOsiz    32          0 - (23**2 - 2)
    Csiz      16          1 - 16 384
    Ssiz(i)   8           NA
    XRsiz(i)  8           1 - 255
    YRsiz(i)  8           1 - 255
    

When determining the size of the buffer for this image, LEADTOOLS performs the following calculation and allocates a buffer for the structure of the image:

    buffer_size = ((Xsiz / XTsiz + 1) * (Ysiz / YTsiz + 1)) * 4
    

Another codestream marker available in JPEG2000 is SOT, start of tile-part. This marker marks the beginning of a tile-part. Its structure is found below:

    Parameter Size (bits) Values
    SOT       16          0xFF90
    Lsot      16          10
    Isot      16          0 - 65535
    Psot      32          0 - (2**32 - 1)
    TPsot     8           0 - 255
    TNsot     8           0 - 255
    

One particular field in the SOT is the Isot, which contains the number of tiles. When parsing the SOT, the buffer allocated from the SIZ parsing is referenced by the Isot value. The buffer containing the image structure information is indexed by the Isot value.

    lfj2ku+0xa1b3
    .text:0000A1B3                 mov     ecx, [edi]
    .text:0000A1B5                 mov     ebx, [ebp+var_18] ; Isot value from file
    .text:0000A1B8                 mov     [ebp+var_28], eax
    .text:0000A1BB                 mov     [ebp+var_34], ecx
    .text:0000A1BE                 mov     eax, [ecx+0B0h]   ; Buffer allocated from SIZ
    .text:0000A1C4                 mov     ebx, [eax+ebx*4]  ; Value read from indexed buffer
    

Assuming the read from the buffer is a pointer (and isn’t -1), the assumed structure offset of 0xA7 is checked to be null. If the value is not null, a null is written in its place.

    lfj2ku+0xa251
    .text:0000A251                 cmp     byte ptr [ebx+0A7h], 0 ; ebx - buffer
    .text:0000A258                 jz      short loc_A27A
    
    lfj2ku+0xa25a
    .text:0000A25A                 mov     ecx, [ebp+var_14]
    .text:0000A25D                 mov     edx, ebx               ; edx - buffer
    .text:0000A25F                 call    sub_9230
    
    ...
    lfj2ku+0x923b
    .text:0000923B                 mov     esi, edx
    .text:0000923D                 mov     [esp+14h+var_4], ecx
    .text:00009241                 push    edi
    .text:00009242                 mov     edi, 1
    .text:00009247                 mov     [esp+18h+var_8], edi
    .text:0000924B                 mov     eax, [esi]
    .text:0000924D                 mov     byte ptr [esi+0A7h], 0 ; esi - buffer
    

If the heap has been aligned correctly, it is possible for an attacker set the values of the above calculations to write an arbitrary null out of bounds, potentially leading to code execution.

**Timeline**

2019-10-31 - Vendor disclosure  
2019-11-06 - Vendor provided timeline for patch  
2019-12-05 - Vendor patched  
2019-12-10 - Public disclosure

Discovered by Cory Duplantis of Cisco Talos.

CVE-2019-5154: TALOS-2019-0945 || Cisco Talos Intelligence Group

Firecracker vsock implementation buffer overflow in versions 0.18.0 and 0.19.0. This can result in potentially exploitable crashes.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[thread-next>\] \[day\] \[month\] \[year\] \[list\]

Date: Tue, 10 Dec 2019 11:30:58 +1100
From: <sandreim@...zon.com>
To: <oss-security@...ts.openwall.com>
CC: "Anthony Liguori (aliguori)" <aliguori@...zon.com>
Subject: CVE-2019-18960: Firecracker v0.18.0 and v0.19.0 vsock buffer overflow

We have identified an issue in the Firecracker v0.18.0 and v0.19.0 vsock
implementation.

# Issue Description

A logical error in bounds checking performed on vsock virtio descriptors
can be used by a malicious guest to read from and write to a segment of
the host-side Firecracker process' heap address space, directly after
the end of a guest memory region. For reads, the accessible segment's
size is 64 KiB. For writes, the accessible segment is limited by the
host Linux kernel to a size defined in /proc/sys/net/core/rmem\_max. We
expect the value of rmem\_max to be on the order of a few hundred KiB to
a few MiB.

# Impact

This will generally result in a segmentation fault, but remote code
execution within the Firecracker host-side process context cannot be
ruled out.

# Vulnerable Systems

Only Firecracker v0.18.0 and v0.19.0 are affected. Only Firecracker
microVMs with configured vsock devices are affected, and only if one or
more vsock devices are in active use by both host and guest.

# Mitigation

Patched binaries for the affected versions have been released as
Firecracker v0.18.1 \[1\] and Firecracker v0.19.1 \[2\].
If you are using Firecracker v0.18.0 or v0.19.0 , we recommend you apply
the provided fix. If you are using Firecracker v0.17.0 or below, you do
not need to take any action.
In a remote code execution scenario, users running Firecracker in line
with the recommended Production Host Setup will see the impact limited
as follows: a malicious microVM guest that would manage to compromise
the Firecracker VMM process would be restricted to running on the host
as an unprivileged user, in a chroot and mount namespace isolated from
the host's filesystem, in a separate pid namespace, in a separate
network namespace, with system calls limited to Firecracker's seccomp
whitelist, on a single NUMA node, and on a cgroups-limited number of CPU
cores.

\[1\] https://github.com/firecracker-microvm/firecracker/releases/tag/v0.18.1
\[2\] https://github.com/firecracker-microvm/firecracker/releases/tag/v0.19.1

Best Regards,
Andrei on behalf of the Firecracker maintainers team.




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

**Download attachment "**pEpkey.asc**" of type "**application/pgp-keys**" (2465 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2019-18960: security - CVE-2019-18960: Firecracker v0.18.0 and v0.19.0 vsock buffer overflow

HTMLDOC 1.9.7 allows a stack-based buffer overflow in the hd_strlcpy() function in string.c (when called from render_contents in ps-pdf.cxx) via a crafted HTML document.

Hi,

While fuzzing htmldoc with Honggfuzz, I found a stack-based buffer overflow in the hd\_strlcpy() function, in string.c.

Attaching a reproducer (gzipped so GitHub accepts it): test01.html.gz

Issue can be reproduced by running:

    htmldoc test01.html -f test01.ps
    

    =================================================================
    ==27915==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffefa66f0df at pc 0x000000494c40 bp 0x7ffefa66f070 sp 0x7ffefa66e838
    WRITE of size 3 at 0x7ffefa66f0df thread T0
        #0 0x494c3f in __asan_memcpy (/home/fcambus/htmldoc-1.9.7/htmldoc/htmldoc+0x494c3f)
        #1 0x556aa5 in hd_strlcpy /home/fcambus/htmldoc-1.9.7/htmldoc/string.c:191:3
        #2 0x509ee3 in render_contents(tree_str*, float, float, float, float, float*, int*, int, tree_str*) /home/fcambus/htmldoc-1.9.7/htmldoc/ps-pdf.cxx:3765:5
        #3 0x4f3cfb in parse_contents(tree_str*, float, float, float, float, float*, int*, int*, tree_str*) /home/fcambus/htmldoc-1.9.7/htmldoc/ps-pdf.cxx:3853:13
        #4 0x4f3f6c in parse_contents(tree_str*, float, float, float, float, float*, int*, int*, tree_str*) /home/fcambus/htmldoc-1.9.7/htmldoc/ps-pdf.cxx
        #5 0x4e4fce in pspdf_export /home/fcambus/htmldoc-1.9.7/htmldoc/ps-pdf.cxx:860:5
        #6 0x4d17bb in main /home/fcambus/htmldoc-1.9.7/htmldoc/htmldoc.cxx:1276:3
        #7 0x7f68626141e2 in __libc_start_main /build/glibc-4WA41p/glibc-2.30/csu/../csu/libc-start.c:308:16
        #8 0x41d84d in _start (/home/fcambus/htmldoc-1.9.7/htmldoc/htmldoc+0x41d84d)
    
    Address 0x7ffefa66f0df is located in stack of thread T0 at offset 63 in frame
        #0 0x5084be in render_contents(tree_str*, float, float, float, float, float*, int*, int, tree_str*) /home/fcambus/htmldoc-1.9.7/htmldoc/ps-pdf.cxx:3563
    
      This frame has 2 object(s):
        [32, 44) 'rgb' (line 3564)
        [64, 1088) 'number' (line 3570) <== Memory access at offset 63 partially underflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/fcambus/htmldoc-1.9.7/htmldoc/htmldoc+0x494c3f) in __asan_memcpy
    Shadow bytes around the buggy address:
      0x10005f4c5dc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5dd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10005f4c5e10: 00 00 00 00 f1 f1 f1 f1 00 04 f2[f2]00 00 00 00
      0x10005f4c5e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5e30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10005f4c5e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    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
    ==27915==ABORTING

CVE-2019-19630: Stack-based buffer overflow in the hd_strlcpy() function · Issue #370 · michaelrsweet/htmldoc

In the Linux kernel before 5.3.9, there is a use-after-free bug that can be caused by a malicious USB device in the drivers/nfc/pn533/usb.c driver, aka CID-6af3aa57a098.

CVE-2019-19526

In the Linux kernel before 5.2.10, there is a use-after-free bug that can be caused by a malicious USB device in the drivers/hid/usbhid/hiddev.c driver, aka CID-9c09b214f30e.

Tag

#buffer_overflow