### Impact

A malicious Matrix server can use a foreign user's MXID in an OpenID exchange, allowing a bad actor to impersonate users when using the provisioning API.

### Details

The library does not check that the servername part of the `sub` parameter (containing the user's *claimed* MXID) is the same as the servername we are talking to. A malicious actor could spin up a server on any given domain, respond with a `sub` parameter according to the user they want to act as and use the resulting token to perform provisioning requests.

### Workarounds

Disable the provisioning API. If the bridge does not use the provisioning API, you are not vulnerable.


**Impact**

A malicious Matrix server can use a foreign user's MXID in an OpenID exchange, allowing a bad actor to impersonate users when using the provisioning API.

**Details**

The library does not check that the servername part of the sub parameter (containing the user's _claimed_ MXID) is the same as the servername we are talking to. A malicious actor could spin up a server on any given domain, respond with a sub parameter according to the user they want to act as and use the resulting token to perform provisioning requests.

**Workarounds**

Disable the provisioning API. If the bridge does not use the provisioning API, you are not vulnerable.

**References**

*   GHSA-vc7j-h8xg-fv5x
*   matrix-org/matrix-appservice-bridge@4c6723a

GHSA-vc7j-h8xg-fv5x: matrix-appservice-bridge doesn't verify the sub parameter of an openId token exhange, allowing unauthorized access to provisioning APIs

static_compressed_inmemory_website_callback.c in Glewlwyd through 2.6.2 allows directory traversal.

@@ -4,7 +4,7 @@ \* \* Copyright 2020-2022 Nicolas Mora <mail@babelouest.org> \* \* Version 20220425 \* Version 20220428 \* \* The MIT License (MIT) \* @@ -89,6 +89,8 @@ \*/ #include <pthread.h\> #include <zlib.h\> #include <limits.h\> #include <stdlib.h\> #include <string.h\> #include <ulfius.h\>  
@@ -158,7 +160,7 @@ static void callback\_static\_file\_uncompressed\_stream\_free(void \* cls) { static int callback\_static\_file\_uncompressed (const struct \_u\_request \* request, struct \_u\_response \* response, void \* user\_data) { size\_t length; FILE \* f; char \* file\_requested, \* file\_path, \* url\_dup\_save; char \* file\_requested, \* file\_path, \* url\_dup\_save, \* real\_path = NULL; const char \* content\_type; int ret = U\_CALLBACK\_CONTINUE;  
@@ -185,34 +187,40 @@ static int callback\_static\_file\_uncompressed (const struct \_u\_request \* request, }  
file\_path = msprintf("%s/%s", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path, file\_requested); real\_path = realpath(file\_path, NULL); if (0 == o\_strncmp(((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path, real\_path, o\_strlen(((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path))) { f = fopen (file\_path, "rb"); if (f) { fseek (f, 0, SEEK\_END); length = ftell (f); fseek (f, 0, SEEK\_SET);  
content\_type = u\_map\_get\_case(&((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->mime\_types, "\*"); y\_log\_message(Y\_LOG\_LEVEL\_WARNING, "Static File Server - Unknown mime type for extension %s", get\_filename\_ext(file\_requested)); } u\_map\_put(response->map\_header, "Content-Type", content\_type); u\_map\_copy\_into(response->map\_header, &((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->map\_header);  
f = fopen (file\_path, "rb"); if (f) { fseek (f, 0, SEEK\_END); length = ftell (f); fseek (f, 0, SEEK\_SET);  
content\_type = u\_map\_get\_case(&((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->mime\_types, "\*"); y\_log\_message(Y\_LOG\_LEVEL\_WARNING, "Static File Server - Unknown mime type for extension %s", get\_filename\_ext(file\_requested)); } u\_map\_put(response->map\_header, "Content-Type", content\_type); u\_map\_copy\_into(response->map\_header, &((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->map\_header);  
if (ulfius\_set\_stream\_response(response, 200, callback\_static\_file\_uncompressed\_stream, callback\_static\_file\_uncompressed\_stream\_free, length, CHUNK, f) != U\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "Static File Server - Error ulfius\_set\_stream\_response"); } } else { if (((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404 == NULL) { ret = U\_CALLBACK\_IGNORE; if (ulfius\_set\_stream\_response(response, 200, callback\_static\_file\_uncompressed\_stream, callback\_static\_file\_uncompressed\_stream\_free, length, CHUNK, f) != U\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "Static File Server - Error ulfius\_set\_stream\_response"); } } else { ulfius\_add\_header\_to\_response(response, "Location", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404); response->status = 302; if (((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404 == NULL) { ret = U\_CALLBACK\_IGNORE; } else { ulfius\_add\_header\_to\_response(response, "Location", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404); response->status = 302; } } o\_free(url\_dup\_save); } else { response->status = 403; } o\_free(file\_path); o\_free(url\_dup\_save); free(real\_path); // realpath uses malloc  
} else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "Static File Server - Error, user\_data is NULL or inconsistent"); ret = U\_CALLBACK\_ERROR; @@ -290,7 +298,7 @@ int callback\_static\_compressed\_inmemory\_website (const struct \_u\_request \* reque unsigned char \* file\_content, \* file\_content\_orig = NULL; size\_t length, read\_length, offset, data\_zip\_len = 0; FILE \* f; char \* file\_requested, \* file\_path, \* url\_dup\_save, \* data\_zip = NULL; char \* file\_requested, \* file\_path, \* url\_dup\_save, \* data\_zip = NULL, \* real\_path = NULL; const char \* content\_type;  
/\* @@ -328,12 +336,11 @@ int callback\_static\_compressed\_inmemory\_website (const struct \_u\_request \* reque compress\_mode = U\_COMPRESS\_DEFL; }  
  
if (compress\_mode != U\_COMPRESS\_NONE) { if (compress\_mode == U\_COMPRESS\_GZIP && config->allow\_cache\_compressed && u\_map\_has\_key(&config->gzip\_files, file\_requested)) { ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->gzip\_files, file\_requested), u\_map\_get\_length(&config->gzip\_files, file\_requested)); u\_map\_put(response->map\_header, U\_CONTENT\_HEADER, U\_ACCEPT\_GZIP);  
content\_type = u\_map\_get\_case(&config->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&config->mime\_types, "\*"); @@ -343,7 +350,7 @@ int callback\_static\_compressed\_inmemory\_website (const struct \_u\_request \* reque } else if (compress\_mode == U\_COMPRESS\_DEFL && config->allow\_cache\_compressed && u\_map\_has\_key(&config->deflate\_files, file\_requested)) { ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->deflate\_files, file\_requested), u\_map\_get\_length(&config->deflate\_files, file\_requested)); u\_map\_put(response->map\_header, U\_CONTENT\_HEADER, U\_ACCEPT\_DEFLATE);  
content\_type = u\_map\_get\_case(&config->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&config->mime\_types, "\*"); @@ -352,120 +359,129 @@ int callback\_static\_compressed\_inmemory\_website (const struct \_u\_request \* reque u\_map\_copy\_into(response->map\_header, &config->map\_header); } else { file\_path = msprintf("%s/%s", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path, file\_requested); real\_path = realpath(file\_path, NULL); if (0 == o\_strncmp(((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path, real\_path, o\_strlen(((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->files\_path))) { if (!pthread\_mutex\_lock(&config->lock)) { f = fopen (file\_path, "rb"); if (f) { content\_type = u\_map\_get\_case(&config->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&config->mime\_types, "\*"); y\_log\_message(Y\_LOG\_LEVEL\_WARNING, "Static File Server - Unknown mime type for extension %s", get\_filename\_ext(file\_requested)); } if (!string\_array\_has\_value((const char \*\*)config->mime\_types\_compressed, content\_type)) { compress\_mode = U\_COMPRESS\_NONE; }  
if (!pthread\_mutex\_lock(&config->lock)) { f = fopen (file\_path, "rb"); if (f) { content\_type = u\_map\_get\_case(&config->mime\_types, get\_filename\_ext(file\_requested)); if (content\_type == NULL) { content\_type = u\_map\_get(&config->mime\_types, "\*"); y\_log\_message(Y\_LOG\_LEVEL\_WARNING, "Static File Server - Unknown mime type for extension %s", get\_filename\_ext(file\_requested)); } if (!string\_array\_has\_value((const char \*\*)config->mime\_types\_compressed, content\_type)) { compress\_mode = U\_COMPRESS\_NONE; }  
u\_map\_put(response->map\_header, "Content-Type", content\_type); u\_map\_copy\_into(response->map\_header, &config->map\_header);  
fseek (f, 0, SEEK\_END); offset = length = ftell (f); fseek (f, 0, SEEK\_SET);  
if (length) { if ((file\_content\_orig = file\_content = o\_malloc(length)) != NULL && (data\_zip = o\_malloc((2\*length)+20)) != NULL) { defstream.zalloc = u\_zalloc; defstream.zfree = u\_zfree; defstream.opaque = Z\_NULL; defstream.avail\_in = (uInt)length; defstream.next\_in = (Bytef \*)file\_content; while ((read\_length = fread(file\_content, sizeof(char), offset, f))) { file\_content += read\_length; offset -= read\_length; }  
if (compress\_mode == U\_COMPRESS\_GZIP) { if (deflateInit2(&defstream, Z\_DEFAULT\_COMPRESSION, Z\_DEFLATED, U\_GZIP\_WINDOW\_BITS | U\_GZIP\_ENCODING, 8, Z\_DEFAULT\_STRATEGY) != Z\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflateInit (gzip)"); ret = U\_CALLBACK\_ERROR; } } else { if (deflateInit(&defstream, Z\_BEST\_COMPRESSION) != Z\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflateInit (deflate)"); ret = U\_CALLBACK\_ERROR; u\_map\_put(response->map\_header, "Content-Type", content\_type); u\_map\_copy\_into(response->map\_header, &config->map\_header);  
fseek (f, 0, SEEK\_END); offset = length = ftell (f); fseek (f, 0, SEEK\_SET);  
if (length) { if ((file\_content\_orig = file\_content = o\_malloc(length)) != NULL && (data\_zip = o\_malloc((2\*length)+20)) != NULL) { defstream.zalloc = u\_zalloc; defstream.zfree = u\_zfree; defstream.opaque = Z\_NULL; defstream.avail\_in = (uInt)length; defstream.next\_in = (Bytef \*)file\_content; while ((read\_length = fread(file\_content, sizeof(char), offset, f))) { file\_content += read\_length; offset -= read\_length; } } if (ret == U\_CALLBACK\_CONTINUE) { do { if ((data\_zip = o\_realloc(data\_zip, data\_zip\_len+\_U\_W\_BLOCK\_SIZE)) != NULL) { defstream.avail\_out = \_U\_W\_BLOCK\_SIZE; defstream.next\_out = ((Bytef \*)data\_zip)+data\_zip\_len; switch ((res = deflate(&defstream, Z\_FINISH))) { case Z\_OK: case Z\_STREAM\_END: case Z\_BUF\_ERROR: break; default: y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflate %d", res); ret = U\_CALLBACK\_ERROR; break; } data\_zip\_len += \_U\_W\_BLOCK\_SIZE - defstream.avail\_out; } else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error allocating resources for data\_zip");  
if (compress\_mode == U\_COMPRESS\_GZIP) { if (deflateInit2(&defstream, Z\_DEFAULT\_COMPRESSION, Z\_DEFLATED, U\_GZIP\_WINDOW\_BITS | U\_GZIP\_ENCODING, 8, Z\_DEFAULT\_STRATEGY) != Z\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflateInit (gzip)"); ret = U\_CALLBACK\_ERROR; } } while (U\_CALLBACK\_CONTINUE == ret && defstream.avail\_out == 0);  
} else { if (deflateInit(&defstream, Z\_BEST\_COMPRESSION) != Z\_OK) { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflateInit (deflate)"); ret = U\_CALLBACK\_ERROR; } } if (ret == U\_CALLBACK\_CONTINUE) { if (compress\_mode == U\_COMPRESS\_GZIP) { if (config->allow\_cache\_compressed) { u\_map\_put\_binary(&config->gzip\_files, file\_requested, data\_zip, 0, defstream.total\_out); do { if ((data\_zip = o\_realloc(data\_zip, data\_zip\_len+\_U\_W\_BLOCK\_SIZE)) != NULL) { defstream.avail\_out = \_U\_W\_BLOCK\_SIZE; defstream.next\_out = ((Bytef \*)data\_zip)+data\_zip\_len; switch ((res = deflate(&defstream, Z\_FINISH))) { case Z\_OK: case Z\_STREAM\_END: case Z\_BUF\_ERROR: break; default: y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error deflate %d", res); ret = U\_CALLBACK\_ERROR; break; } data\_zip\_len += \_U\_W\_BLOCK\_SIZE - defstream.avail\_out; } else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error allocating resources for data\_zip"); ret = U\_CALLBACK\_ERROR; } ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->gzip\_files, file\_requested), u\_map\_get\_length(&config->gzip\_files, file\_requested)); } else { if (config->allow\_cache\_compressed) { u\_map\_put\_binary(&config->deflate\_files, file\_requested, data\_zip, 0, defstream.total\_out); } while (U\_CALLBACK\_CONTINUE == ret && defstream.avail\_out == 0);  
if (ret == U\_CALLBACK\_CONTINUE) { if (compress\_mode == U\_COMPRESS\_GZIP) { if (config->allow\_cache\_compressed) { u\_map\_put\_binary(&config->gzip\_files, file\_requested, data\_zip, 0, defstream.total\_out); } ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->gzip\_files, file\_requested), u\_map\_get\_length(&config->gzip\_files, file\_requested)); } else { if (config->allow\_cache\_compressed) { u\_map\_put\_binary(&config->deflate\_files, file\_requested, data\_zip, 0, defstream.total\_out); } ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->deflate\_files, file\_requested), u\_map\_get\_length(&config->deflate\_files, file\_requested)); } ulfius\_set\_binary\_body\_response(response, 200, u\_map\_get(&config->deflate\_files, file\_requested), u\_map\_get\_length(&config->deflate\_files, file\_requested)); u\_map\_put(response\->map\_header, U\_CONTENT\_HEADER, compress\_mode==U\_COMPRESS\_GZIP?U\_ACCEPT\_GZIP:U\_ACCEPT\_DEFLATE); } u\_map\_put(response->map\_header, U\_CONTENT\_HEADER, compress\_mode==U\_COMPRESS\_GZIP?U\_ACCEPT\_GZIP:U\_ACCEPT\_DEFLATE); } deflateEnd(&defstream); o\_free(data\_zip); } else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error allocating resource for file\_content or data\_zip"); ret = U\_CALLBACK\_ERROR; } deflateEnd(&defstream); o\_free(data\_zip); o\_free(file\_content\_orig); } fclose(f); } else { if (((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404 == NULL) { ret = U\_CALLBACK\_IGNORE; } else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error allocating resource for file\_content or data\_zip"); ret = U\_CALLBACK\_ERROR; ulfius\_add\_header\_to\_response(response, "Location", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404); response->status = 302; } o\_free(file\_content\_orig); } fclose(f); pthread\_mutex\_unlock(&config->lock); } else { if (((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404 == NULL) { ret = U\_CALLBACK\_IGNORE; } else { ulfius\_add\_header\_to\_response(response, "Location", ((struct \_u\_compressed\_inmemory\_website\_config \*)user\_data)->redirect\_on\_404); response->status = 302; } y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error pthread\_lock\_mutex"); ret = U\_CALLBACK\_ERROR; } pthread\_mutex\_unlock(&config->lock); } else { y\_log\_message(Y\_LOG\_LEVEL\_ERROR, "callback\_static\_compressed\_inmemory\_website - Error pthread\_lock\_mutex"); ret = U\_CALLBACK\_ERROR; response->status = 403; } o\_free(file\_path); free(real\_path); // realpath uses malloc } } else { ret = callback\_static\_file\_uncompressed(request, response, user\_data); } free\_string\_array(accept\_list); } else { ret = callback\_static\_file\_uncompressed(request, response, user\_data); } } else { ret = callback\_static\_file\_uncompressed(request, response, user\_data); } o\_free(url\_dup\_save); }

CVE-2022-29967: Fix file access check for directory traversal, and fix call for callb… · babelouest/glewlwyd@e3f7245

ADMesh through 0.98.4 has a heap-based buffer over-read in stl_update_connects_remove_1 (called from stl_remove_degenerate) in connect.c in libadmesh.a.

Find a heap-buffer-overflow with the input. Hope this report is helpful.

    ADMesh version 0.99.0dev, Copyright (C) 1995, 1996 Anthony D. Martin
    ADMesh comes with NO WARRANTY.  This is free software, and you are welcome to
    redistribute it under certain conditions.  See the file COPYING for details.
    Opening 0
    Checking exact...
    Checking nearby. Tolerance= 3.937008 Iteration=1 of 2...  Fixed 2 edges.
    Checking nearby. Tolerance= 196854.328125 Iteration=2 of 2...  Fixed 0 edges.
    Removing unconnected facets...
    =================================================================
    ==29577==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x610000000030 at pc 0x7f791f89fefe bp 0x7fffd3395da0 sp 0x7fffd3395d98
    READ of size 4 at 0x610000000030 thread T0
        #0 0x7f791f89fefd in stl_update_connects_remove_1 /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/connect.c:831:9
        #1 0x7f791f89fefd in stl_remove_degenerate /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/connect.c:796
        #2 0x7f791f89fefd in stl_remove_unconnected_facets /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/connect.c:728
        #3 0x7f791f8cf622 in stl_repair /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/util.c:527:7
        #4 0x51a148 in main /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/admesh.c:303:3
        #5 0x7f791e8dab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
        #6 0x41af79 in _start (/home/t/Projects/afl/fuzzing-experiments/subjects/admesh/.libs/admesh+0x41af79)
    
    0x610000000030 is located 16 bytes to the left of 192-byte region [0x610000000040,0x610000000100)
    allocated by thread T0 here:
        #0 0x4e382f in calloc /home/t/Projects/lldb-testing/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:155
        #1 0x7f791f8b5239 in stl_allocate /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/stlinit.c:185:26
        #2 0x7f791f8b5239 in stl_open /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/stlinit.c:42
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/t/Projects/afl/fuzzing-experiments/subjects/admesh/src/connect.c:831:9 in stl_update_connects_remove_1
    Shadow bytes around the buggy address:
      0x0c207fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c207fff8000: fa fa fa fa fa fa[fa]fa 00 00 00 00 00 00 00 00
      0x0c207fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c207fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c207fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c207fff8050: 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
    ==29577==ABORTING

CVE-2018-25033: heap-buffer-flow in stl_update_connects_remove_1 · Issue #28 · admesh/admesh

An authentication bypass vulnerability exists in the device password generation functionality of Swift Sensors Gateway SG3-1010. A specially-crafted network request can lead to remote code execution. An attacker can send a sequence of requests to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the device password generation functionality of Swift Sensors Gateway SG3-1010. A specially-crafted network request can lead to remote code execution. An attacker can send a sequence of requests to trigger this vulnerability.

**Tested Versions**

Swift Sensors Gateway SG3-1010

**Product URLs**

Swift Sensors Gateway - https://www.swiftsensors.com/catalog/gateways/sg3-1010/

**CVSSv3 Score**

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

**CWE**

CWE-798 - Use of Hard-coded Credentials

**Details**

The Swift Sensors Gateway 1010 connects with all Series 3 Swift Sensors within range and securely transmits sensor data to the Swift Sensors Cloud through either Wi-Fi, Ethernet or Cellular (Swift Sensors Cellular Network Module Required).

While typical installation and usage does not require a user to login to the device itself, a `SSH` service can be found running on the device by default. This service is not required for standard operation and is not mentioned in the provided documentation, nor are any sort of login credentials.

However, upon analysis of the device firmware, we were able to determine their unique password generation mechanism for each device. This password is based off of the exposed `Gateway ID` printed boldly on the front of each gateway. This ID consists of 8 alphanumeric characters that are used in a substitution & encoding process that is eventually AES encrypted and base64 encoded. The base64 encoded value along with the username `pi` (this is a Raspberry Pi device with a customized ‘HAT’ for receiving sensor data), allows any user on the network (or if the gateway is exposed to the internet) that knows or can see the printed `Gateway ID` to login to the device using the exposed `SSH` service. From there, a user can `sudo su` straight to the `root` user.

Also of note is that the device ID and password combination is used by the Swift Sensor bridge software itself to login to the backend to report sensor data. This could potentially allow a remote user to manipulate data and/or disable sensor reporting altogether. Additionally, our research indicates that only the last 4 characters differ between bridge IDs using only capital letters and/or numbers. This small keyspace (36^4) means that an attacker could in theory, brute-force each possible device ID and password combination to login to the backend sensor data endpoint as those devices.This is particularly critical considering the sensor package we were sold is designed specifically for monitoring Moderna vaccine equipment.

**Exploit Proof of Concept**

$ ssh pi@192.168.1.223 pi@192.168.1.223’s password: Linux WBERN3-01-AYM6LWFB 5.4.81-v7l+ #1378 SMP Mon Dec 7 18:43:09 GMT 2020 armv7l

The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/\*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Nov 29 15:51:43 2021 from 192.168.1.224 pi@WBERN3-01-AYM6LWFB:~$ sudo su root@WBERN3-01-AYM6LWFB:/home/pi# whoami root root@WBERN3-01-AYM6LWFB:/home/pi# uname -a Linux WBERN3-01-AYM6LWFB 5.4.81-v7l+ #1378 SMP Mon Dec 7 18:43:09 GMT 2020 armv7l GNU/Linux root@WBERN3-01-AYM6LWFB:/home/pi#

**Timeline**

2021-12-14 - Vendor disclosure  
2021-12-14 - Initial vendor contact  
2022-02-02 - Vendor patched  
2022-02-28 - Public Release  

Discovered by Dave McDaniel of Cisco Talos.

CVE-2021-40422: TALOS-2021-1431 || Cisco Talos Intelligence Group

libtiff 4.5.0 is vulnerable to Buffer Overflow in uv_encode() when libtiff reads a corrupted little-endian TIFF file and specifies the output to be big-endian.

Skip to content

**Get started with Code Suggestions, available for free during the beta period.**

Code faster and more efficiently with AI-powered code suggestions in VS Code. 13 languages are supported, including JavaScript, Python, Go, Java, and Kotlin. Enable Code Suggestions in your user profile preferences or see the documentation to learn more.

*   libtiff
*   libtiff
*   Issues
*   #530

Open Issue created Feb 15, 2023 by **Tseng Szu Wei@13579and24680**

**SEGV at /libtiff/tif\_luv.c:961 in uv\_encode()**

**Summary**

An SIGSEGV caused when using tiffcrop.

**Version**

    $ ./tools/tiffcrop -v
    Library Release: LIBTIFF, Version 4.5.0
    Copyright (c) 1988-1996 Sam Leffler
    Copyright (c) 1991-1996 Silicon Graphics, Inc.
    Tiffcp code: Copyright (c) 1988-1997 Sam Leffler
               : Copyright (c) 1991-1997 Silicon Graphics, Inc
    Tiffcrop additions: Copyright (c) 2007-2010 Richard Nolde
    
    $ git log --oneline -1
    c861f25c (HEAD -> master, origin/master, origin/HEAD) Merge branch 'tiffcrop_dont_reuse_input_buffer_fix_527' into 'master'

**Steps to reproduce****make**

    git clone https://gitlab.com/libtiff/libtiff.git
    cd libtiff
    ./autogen.sh
    ./configure
    make

**run**

    $ ./tools/tiffcrop -B poc temp
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 3120 (0xc30) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 3120 (Tag 3120) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFAdvanceDirectory: Error fetching directory count.
    fish: Job 1, './tools/tiffcrop -B poc temp' terminated by signal SIGSEGV (Address boundary error)

**Platform**

    $ uname -a
    Linux 13579 5.15.0-56-generic #62~20.04.1-Ubuntu SMP Tue Nov 22 21:24:20 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    
    $ gcc --version
    gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
    Copyright (C) 2019 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

**ASAN report**

    ./tools/tiffcrop -B poc temp
    TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order.
    TIFFReadDirectory: Warning, Unknown field with tag 12336 (0x3030) encountered.
    TIFFReadDirectory: Warning, Unknown field with tag 3120 (0xc30) encountered.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 12336 (Tag 12336) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFFetchNormalTag: Defined set_field_type of custom tag 3120 (Tag 3120) is TIFF_SETGET_UNDEFINED and thus tag is not read from file.
    TIFFAdvanceDirectory: Error fetching directory count.
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==1381705==ERROR: AddressSanitizer: SEGV on unknown address 0x7f1876003420 (pc 0x7f1c75f78cb0 bp 0x7ffc95fdf630 sp 0x7ffc95fdf600 T0)
    ==1381705==The signal is caused by a READ memory access.
        #0 0x7f1c75f78caf in uv_encode /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:961
        #1 0x7f1c75f797b2 in LogLuv24fromXYZ /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:1057
        #2 0x7f1c75f79f58 in Luv24fromXYZ /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:1120
        #3 0x7f1c75f76522 in LogLuvEncode24 /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:569
        #4 0x7f1c75f775c7 in LogLuvEncodeStrip /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:722
        #5 0x7f1c75fcb6bb in TIFFWriteEncodedStrip /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_write.c:308
        #6 0x563fd6857160 in writeBufferToContigStrips /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:1317
        #7 0x563fd688022e in writeCroppedImage /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:9197
        #8 0x563fd685f4d5 in main /home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/tiffcrop.c:2834
        #9 0x7f1c75a96082 in __libc_start_main ../csu/libc-start.c:308
        #10 0x563fd6855b6d in _start (/home/a13579/fuzz_lib_tiff/report/libtiff_asan/tools/.libs/tiffcrop+0x9b6d)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/a13579/fuzz_lib_tiff/report/libtiff_asan/libtiff/tif_luv.c:961 in uv_encode
    ==1381705==ABORTING

**poc**

poc

CVE-2023-26966: SEGV at /libtiff/tif_luv.c:961 in uv_encode() (#530) · Issues · libtiff / libtiff · GitLab

Categories: News
Tags: Google

Tags:  Chromium

Tags:  Rust

Tags:  memory safety

Tags:  rule of two

Google has announced that it will support the use of third-party Rust libraries in Chromium which is a step forward in memory safety for the browsers.



(Read more...)




The post Google to support the use of Rust in Chromium appeared first on Malwarebytes Labs.

In a blog by the Chrome security team we learned that the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium.

This is good news because Rust is a so-called memory-safe programming language. So using it in a widespread program like Chrome and the other members of the Chromium family means that almost everyone can benefit from this step forward.

Besides Google’s own Chrome browser, Microsoft Edge, Opera, and many other browsers are based on Chromium code. Reportedly, there are over 25 million lines of code in 36 programming languages in the Chromium browser codebase.

**Rust**

Rust is a community project and the product is a high-level, general-purpose programming language that enforces memory safety. Rust started in 2006 as a personal project by Mozilla Research employee Graydon Hoare as part of the development of the Servo browser engine. Then, in February 2021, the Servo team was disbanded and the Rust Foundation was announced by its five founding companies (AWS, Huawei, Google, Microsoft, and Mozilla).

Rust is designed to be memory safe, because poor memory management has been the root cause for way too many vulnerabilities, for way too long. Only a few months ago, the NSA urged a shift to memory safe programming languages.

**Memory vulnerabilities**

If you ever read our posts describing security vulnerabilities, you will see a lot of phrases like "buffer overflow", "failure to release memory", "use after free", "memory corruption", and "memory leak". These are all memory management issues. And the best way to prevent memory management issues is to use a memory-safe language, which manages memory automatically instead of relying on a programmer to code things correctly.

In an earlier article about the effects of the introduction of memory safe languages in Android we showed a steady decline of memory safety vulnerabilities in Android. With the introduction of memory-safe languages like Kotlin, Java, and Rust in the development of the Android operating system, the contributions to the software that ties everything together in the background coded in C and C++ have gone down considerably.

**Rule of two**

Google’s goals for allowing the use of Rust libraries in Chromium are to provide a simpler and safer way to satisfy the rule of two, in order to speed up development and improve the security of Chrome.

The rule of two is demonstrated in the image below:

_Image courtesy of Google_

It says not to pick more than two of these possibly unsafe circumstances:

*   untrustworthy inputs
*   unsafe implementation language
*   high privilege

By eliminating the “code written in an unsafe language” factor wherever you can, you lessen the need to run code in a sandbox. So, there is less code needed and less need for security reviews. This speeds up development while improving the security. Eliminating the untrustworthy input is almost impossible when you are working on a browser.

The Chrome browser runs as an OS-level account representing a person which is considered a high privilege. In Chrome, sandboxing is applied to attain privilege reduction, which means running the code in a process that has had some or many of its privileges revoked.

**Libraries**

Rust was set out to be the foundation for a secure browser and has already proven its use in a browser for Mozilla. But for now, Google will only support third-party libraries. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium.

For future developments, Google is investing in Crubit, an experiment in how to increase the fidelity of interop between C++ and Rust and express or encapsulate the requirements of each language to the other.  Interop refers to two or more browsers behaving the same.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Google to support the use of Rust in Chromium

Observable response discrepancy in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.

**Select Your Region**

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**Intel® Processors Software Developer Guidance Advisory**

**Summary: **

Potential security vulnerabilities in some Intel® Processors may allow information disclosure.  Intel is releasing updated software developer prescriptive guidance to address these potential vulnerabilities.

**Vulnerability Details:**

CVEID:  CVE-2021-0086

Description: Observable response discrepancy in floating-point operations for some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.

CVSS Base Score: 6.5 Medium

CVSS Vector:  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

CVEID: CVE-2021-0089

Description: Observable response discrepancy in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access.

CVSS Base Score: 6.5 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

**Affected Products:**

All Intel® Processor families.

**Recommendations:**

For CVE-2021-0086  Intel recommends that affected software including web browser JavaScript engine that runs on Intel® Processors follow one of the below guidelines: 

•       Process isolation.

•       Use alternatives to NaN-boxing techniques (eg. Dedicated type tag).

•       Constraining FP results before potential type-confused usage.

Additional technical details can be found here.

For CVE-2021-0089 Intel recommends that affected software that runs on Intel® Processors follow one of the below guidelines:

•       Process isolation.

•       Place serializing operations between code gen and execution.

•       Place LFENCE-semantic operations between code gen and execution.

•       Options include LFENCE, SYSCALL/SYSRET

Additional technical details can be found here.

**Acknowledgements:**

Intel would like to thank Enrico Barberis, Hany Ragab, Herbert Bos, and Cristiano Giuffrida from the VUSec group at VU Amsterdam for reporting these issues.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

06/08/2021

Initial Release

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at https://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  
Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

CVE-2021-0089: INTEL-SA-00516

Due to a too loose type check in an API method, attackers could bypass the directory traversal check by providing an invalid UTF-8 encoding sequence.

Skip to content

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  GHSA-gj48-w74w-8gvm

**Path Traversal in TYPO3 Core**

Moderate severity GitHub Reviewed Published Feb 22, 2024 to the GitHub Advisory Database • Updated Feb 22, 2024

**Package**

**Affected versions**

\>= 6.2.0, < 6.2.29

\>= 7.6.0, < 7.6.13

\>= 8.0.0, < 8.4.1

**Patched versions**

6.2.29

7.6.13

8.4.1

**Description**

Published to the GitHub Advisory Database

Feb 22, 2024

Last updated

Feb 22, 2024

GHSA-gj48-w74w-8gvm: Path Traversal in TYPO3 Core

Buffer Overflow vulnerability in Supermicro motherboard X12DPG-QR 1.4b allows local attackers to hijack control flow via manipulation of SmcSecurityEraseSetupVar variable.

Variable Modification Due to Stack Overflow

**Vulnerability Disclosure:**

The purpose of this vulnerability disclosure is to communicate the potential vulnerability affecting Supermicro products that was reported by an external researcher.

**Acknowledgement:**

Supermicro would like to acknowledge the work done by the researcher from Wuhan University, China for discovering a potential vulnerability in the X12DPG-QR motherboard.

**Findings:**

Possible stack overflow occurrence in the BIOS firmware may allow an attacker to exploit this vulnerability by manipulating a variable to potentially hijack the control flow, allowing attackers with the kernel level privileges to escalate their privileges and potentially leading to the execution of arbitrary code.

**CVE:**

*   CVE-2023-34853
*   **Severity**: High

**Affected products:**

Supermicro BIOS in X11, X12, X13, and H11, H12, H13 motherboards.

**Solution:**

All affected Supermicro motherboard SKUs will require a BIOS update to mitigate this potential vulnerability.

An updated BIOS firmware had been created to mitigate this potential vulnerability. Supermicro is currently testing and validating affected products. Please check Release Notes for the resolution.

Search

lenovo warranty check/lookup | check warranty status | lenovo support us