### Impact
HTML files crafted to look like images may be uploaded regardless of mime validation. This is only applicable on front-end forms using the "Forms" feature containing an assets field, or within the control panel which requires authentication.

### Patches
It has been patched on 3.4.15 and 4.36.0.

Skip to content

Sign up

**CVE-2023-48701**

*   *   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
        
    
    Explore
    
    *   All features
    *   Documentation
    *   GitHub Skills
    *   Blog
    
*   For
    
    *   Enterprise
    *   Teams
    *   Startups
    *   Education
    
    By Solution
    
    *   CI/CD & Automation
    *   DevOps
    *   DevSecOps
    
    Resources
    
    *   Learning Pathways
    *   White papers, Ebooks, Webinars
    *   Customer Stories
    *   Partners
    
*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
    Repositories
    
    *   Topics
    *   Trending
    *   Collections
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

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

Sign in

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2023-48701

**Cross-site Scripting via uploaded assets**

High severity GitHub Reviewed Published Nov 21, 2023 in statamic/cms

Vulnerability details Dependabot alerts 0

**Package**

composer statamic/cms (Composer)

**Affected versions**

< 3.4.15

\>= 4.0.0, < 4.36.0

**Patched versions**

3.4.15

4.36.0

**Description**

**Impact**

HTML files crafted to look like images may be uploaded regardless of mime validation. This is only applicable on front-end forms using the "Forms" feature containing an assets field, or within the control panel which requires authentication.

**Patches**

It has been patched on 3.4.15 and 4.36.0.

**References**

*   GHSA-8jjh-j3c2-cjcv
*   https://nvd.nist.gov/vuln/detail/CVE-2023-48701
*   https://github.com/statamic/cms/releases/tag/v3.4.15
*   https://github.com/statamic/cms/releases/tag/v4.36.0

 jasonvarga published to statamic/cms

Nov 21, 2023

Published by the National Vulnerability Database

Nov 21, 2023

Published to the GitHub Advisory Database

Nov 22, 2023

Reviewed

Nov 22, 2023

**Severity**

High

7.5

/ 10

**CVSS base metrics**

Attack vector

Network

Attack complexity

High

Privileges required

None

User interaction

Required

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

High

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

**Weaknesses**

CWE-79

**CVE ID**

CVE-2023-48701

**GHSA ID**

GHSA-8jjh-j3c2-cjcv

**Source code**

statamic/cms

**Credits**

*    Cyber-Wo0dy Reporter

Checking history

See something to contribute? Suggest improvements for this vulnerability.

GHSA-8jjh-j3c2-cjcv: Cross-site Scripting via uploaded assets

Draytek Vigor2960 v1.5.1.4 and v1.5.1.5 are vulnerable to directory traversal via the mainfunction.cgi dumpSyslog 'option' parameter allowing an authenticated attacker with access to the web management interface to delete arbitrary files. Vigor2960 is no longer supported.

*   *   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

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

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

Sign up

CVE-2023-6265: Vuln/Draytek/4.md at main · xxy1126/Vuln

IBM Cloud Pak for Security (CP4S) 1.10.0.0 through 1.10.11.0 and IBM QRadar Suite Software 1.10.12.0 through 1.10.16.0could allow an authenticated user to obtain sensitive version information that could aid in further attacks against the system.  IBM X-Force ID:  233665.

CVE-2022-36777: Security Bulletin: QRadar Suite Software includes components with multiple known vulnerabilities

Directory Traversal vulnerability in jeecg-boot v.3.6.0 allows a remote privileged attacker to obtain sensitive information via the file directory structure.

**Directory Traversal in jeecg-boot**

Moderate severity GitHub Reviewed Published Nov 22, 2023 to the GitHub Advisory Database • Updated Nov 22, 2023

GHSA-rgg9-264h-3hfw: Directory Traversal in jeecg-boot

SwiftyEdit Content Management System prior to v1.2.0 is vulnerable to Cross Site Request Forgery (CSRF).

**Cross Site Request Forgery in SwiftyEdit**

Moderate severity GitHub Reviewed Published Nov 22, 2023 to the GitHub Advisory Database • Updated Nov 22, 2023

GHSA-2492-xxqf-6h78: Cross Site Request Forgery in SwiftyEdit

Libde265 v1.0.12 was discovered to contain multiple buffer overflows via the num_tile_columns and num_tile_row parameters in the function pic_parameter_set::dump.

**Summary**

There is a segmentation fault caused by a buffer over-read on pic\_parameter\_set::dump due to an incorrect value of num\_tile\_columns or num\_tile\_rows.

**Tested with:**

*   Commit: 6fc550f (master)
*   PoC: poc
*   cmd: ./dec265 -d poc

**Crash output:**

    INFO: ----------------- SPS -----------------
    INFO: video_parameter_set_id  : 0
    INFO: sps_max_sub_layers      : 1
    INFO: sps_temporal_id_nesting_flag : 1
    INFO:   general_profile_space     : 0
    INFO:   general_tier_flag         : 0
    INFO:   general_profile_idc       : Main
    INFO:   general_profile_compatibility_flags: 0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
    INFO:     general_progressive_source_flag : 0
    INFO:     general_interlaced_source_flag : 0
    INFO:     general_non_packed_constraint_flag : 0
    INFO:     general_frame_only_constraint_flag : 0
    INFO:   general_level_idc         : 60 (2.00)
    INFO: seq_parameter_set_id    : 0
    INFO: chroma_format_idc       : 1 (4:2:0)
    INFO: pic_width_in_luma_samples  : 416
    INFO: pic_height_in_luma_samples : 240
    INFO: conformance_window_flag    : 1
    INFO: conf_win_left_offset  : 0
    INFO: conf_win_right_offset : 0
    INFO: conf_win_top_offset   : 0
    INFO: conf_win_bottom_offset: 0
    INFO: bit_depth_luma   : 10
    INFO: bit_depth_chroma : 9
    INFO: log2_max_pic_order_cnt_lsb : 4
    INFO: sps_sub_layer_ordering_info_present_flag : 1
    INFO: Layer 0
    INFO:   sps_max_dec_pic_buffering      : 5
    INFO:   sps_max_num_reorder_pics       : 3
    INFO:   sps_max_latency_increase_plus1 : 0
    INFO: log2_min_luma_coding_block_size : 3
    INFO: log2_diff_max_min_luma_coding_block_size : 1
    INFO: log2_min_transform_block_size   : 2
    INFO: log2_diff_max_min_transform_block_size : 2
    INFO: max_transform_hierarchy_depth_inter : 0
    INFO: max_transform_hierarchy_depth_intra : 0
    INFO: scaling_list_enable_flag : 0
    INFO: amp_enabled_flag                    : 1
    INFO: sample_adaptive_offset_enabled_flag : 1
    INFO: pcm_enabled_flag                    : 0
    INFO: num_short_term_ref_pic_sets : 11
    INFO: ref_pic_set[  0 ]: X...X.X.X.......|................
    INFO: ref_pic_set[  1 ]: ..........X.X...|...X............
    INFO: ref_pic_set[  2 ]: ............X.X.|.X...X..........
    INFO: ref_pic_set[  3 ]: ...............X|X.X...X.........
    INFO: ref_pic_set[  4 ]: .............X.X|X...X...........
    INFO: ref_pic_set[  5 ]: ..........X.X.X.|.X..............
    INFO: ref_pic_set[  6 ]: ...........X...X|X.X.............
    INFO: ref_pic_set[  7 ]: .............X..|X.X.X...........
    INFO: ref_pic_set[  8 ]: ........X.......|................
    INFO: ref_pic_set[  9 ]: ............X...|...X............
    INFO: ref_pic_set[ 10 ]: ..............X.|.X...X..........
    INFO: long_term_ref_pics_present_flag : 0
    INFO: sps_temporal_mvp_enabled_flag      : 1
    INFO: strong_intra_smoothing_enable_flag : 1
    INFO: vui_parameters_present_flag        : 1
    INFO: sps_extension_present_flag    : 0
    INFO: sps_range_extension_flag      : 0
    INFO: sps_multilayer_extension_flag : 0
    INFO: sps_extension_6bits           : 0
    INFO: CtbSizeY     : 16
    INFO: MinCbSizeY   : 8
    INFO: MaxCbSizeY   : 16
    INFO: MinTBSizeY   : 4
    INFO: MaxTBSizeY   : 16
    INFO: PicWidthInCtbsY         : 26
    INFO: PicHeightInCtbsY        : 15
    INFO: SubWidthC               : 2
    INFO: SubHeightC              : 2
    INFO: ----------------- VUI -----------------
    INFO: sample aspect ratio        : 0:0
    INFO: overscan_info_present_flag : 0
    INFO: overscan_appropriate_flag  : 0
    INFO: video_signal_type_present_flag: 0
    INFO: chroma_loc_info_present_flag: 0
    INFO: neutral_chroma_indication_flag: 0
    INFO: field_seq_flag                : 0
    INFO: frame_field_info_present_flag : 0
    INFO: default_display_window_flag   : 1
    INFO:   def_disp_win_left_offset    : 0
    INFO:   def_disp_win_right_offset   : 0
    INFO:   def_disp_win_top_offset     : 0
    INFO:   def_disp_win_bottom_offset  : 0
    INFO: vui_timing_info_present_flag  : 0
    INFO: vui_poc_proportional_to_timing_flag : 0
    INFO: vui_num_ticks_poc_diff_one          : 1
    INFO: vui_hrd_parameters_present_flag : 0
    INFO: bitstream_restriction_flag         : 0
    INFO: ----------------- PPS -----------------
    INFO: pic_parameter_set_id       : 0
    INFO: seq_parameter_set_id       : 0
    INFO: dependent_slice_segments_enabled_flag : 1
    INFO: sign_data_hiding_flag      : 1
    INFO: cabac_init_present_flag    : 0
    INFO: num_ref_idx_l0_default_active : -84
    INFO: num_ref_idx_l1_default_active : 12
    INFO: pic_init_qp                : 25
    INFO: constrained_intra_pred_flag: 0
    INFO: transform_skip_enabled_flag: 1
    INFO: cu_qp_delta_enabled_flag   : 0
    INFO: pic_cb_qp_offset             : 1
    INFO: pic_cr_qp_offset             : 0
    INFO: pps_slice_chroma_qp_offsets_present_flag : 0
    INFO: weighted_pred_flag           : 0
    INFO: weighted_bipred_flag         : 1
    INFO: output_flag_present_flag     : 0
    INFO: transquant_bypass_enable_flag: 0
    INFO: tiles_enabled_flag           : 1
    INFO: entropy_coding_sync_enabled_flag: 0
    INFO: num_tile_columns    : 18815
    INFO: num_tile_rows       : 1
    INFO: uniform_spacing_flag: 1
    INFO: tile column boundaries: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3985 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [1]    4017733 segmentation fault  ./dec265 -d poc
    

**Analysis**

While executing decoder_context::read_pps_NAL, parameters are read in

bool success = new\_pps->read(&reader,this);

Inside the function, there is a check when setting num_tile_columns in case it goes over DE265_MAX_TILE_COLUMNS, which is 10.

  if (tiles\_enabled\_flag) {
    num\_tile\_columns = get\_uvlc(br);
    if (num\_tile\_columns == UVLC\_ERROR ||
	num\_tile\_columns+1 > DE265\_MAX\_TILE\_COLUMNS) {
      ctx->add\_warning(DE265\_WARNING\_PPS\_HEADER\_INVALID, false);
      return false;
    }

After exiting due to reading more than DE265_MAX_TILE_COLUMNS, the headers are dumped by calling dump:

  bool success = new\_pps->read(&reader,this);

  if (param\_pps\_headers\_fd>=0) {
    new\_pps->dump(param\_pps\_headers\_fd);
  }

  if (success) {
    pps\[ (int)new\_pps->pic\_parameter\_set\_id \] = new\_pps;
  }

In dump, the following code is executed to dump the tile column boundaries:

    LOG0("tile column boundaries: ");
    for (int i=0;i<=num\_tile\_columns;i++) {
      LOG1("\*%d ",colBd\[i\]);
    }
    LOG0("\*\\n");

As previously shown, num_tile_columns while be set to a higher number than DE265_MAX_TILE_COLUMNS. colBd is defined as:

int colBd    [ DE265_MAX_TILE_COLUMNS+1 ];

Therefore, that loop will go over colBd and will print all the data pointed by the values found after the limits of colBd in memory until the end of the loop or the next memory address is invalid.

**Impact**

*   Information leak from memory
*   Crash

If using a carefully crafted exploit, the impact could be an information leak without a crash.

**Patch**

In order to prevent this, the success value should be checked before printing the information:

diff --git a/libde265/decctx.cc b/libde265/decctx.cc
index 223a6aaf..1b79adec 100644
\--- a/libde265/decctx.cc
+++ b/libde265/decctx.cc
@@ -583,11 +583,10 @@ de265\_error decoder\_context::read\_pps\_NAL(bitreader& reader)
 
   bool success = new\_pps->read(&reader,this);
 
\-  if (param\_pps\_headers\_fd>=0) {
\-    new\_pps->dump(param\_pps\_headers\_fd);
\-  }
\-
   if (success) {
+    if (param\_pps\_headers\_fd>=0) {
+      new\_pps->dump(param\_pps\_headers\_fd);
+    }
     pps\[ (int)new\_pps->pic\_parameter\_set\_id \] = new\_pps;
   }

Another possibility could be to perform length checks inside the dump function to handle the case:

diff --git a/libde265/pps.cc b/libde265/pps.cc
index de3bcda1..a5abd9b3 100644
\--- a/libde265/pps.cc
+++ b/libde265/pps.cc
@@ -903,14 +903,22 @@ void pic\_parameter\_set::dump(int fd) const
     LOG1("uniform\_spacing\_flag: %d\\n", uniform\_spacing\_flag);
 
     LOG0("tile column boundaries: ");
\-    for (int i=0;i<=num\_tile\_columns;i++) {
\-      LOG1("\*%d ",colBd\[i\]);
+    if (num\_tile\_columns+1 > DE265\_MAX\_TILE\_COLUMNS) {
+      LOG0("Number of tile columns is invalid");
+    } else {
+      for (int i=0;i<=num\_tile\_columns;i++) {
+        LOG1("\*%d ",colBd\[i\]);
+      }
     }
     LOG0("\*\\n");
 
     LOG0("tile row boundaries: ");
\-    for (int i=0;i<=num\_tile\_rows;i++) {
\-      LOG1("\*%d ",rowBd\[i\]);
+    if (num\_tile\_rows+1 > DE265\_MAX\_TILE\_ROWS) {
+      LOG0("Number of tile rows is invalid");
+    } else {
+      for (int i=0;i<=num\_tile\_rows;i++) {
+        LOG1("\*%d ",rowBd\[i\]);
+      }
     }
     LOG0("\*\\n");

**Other notes**

The same issue occurs with num_tile_rows.

CVE-2023-43887: Buffer over-read causes segmentation fault in pic_parameter_set::dump · Issue #418 · strukturag/libde265

Buffer Overflow vulnerability in zlib-ng minizip-ng v.4.0.2 allows an attacker to execute arbitrary code via a crafted file to the mz_path_resolve function in the mz_os.c file.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Akane0721 opened this issue

Nov 8, 2023

· 5 comments

**Comments**

**Description**

heap-buffer-overflow (/minizip-ng/build/minizip+0x976d) in mz\_path\_resolve

**Version**

$ ./minizip -h
minizip-ng 4.0.2 - https://github.com/zlib-ng/minizip-ng
---------------------------------------------------
-h 
Usage: minizip \[-x\]\[-d dir|\-l|\-e\]\[-o\]\[-f\]\[-y\]\[-c cp\]\[-a\]\[-0 to -9\]\[-b|\-m|\-t\]\[-k 512\]\[-p pwd\]\[-s\] file.zip \[files\]

  -x  Extract files
  -l  List files
  -d  Destination directory
  -e  Erase files
  -o  Overwrite existing files
  -c  File names use cp437 encoding (or specified codepage)
  -a  Append to existing zip file
  -i  Include full path of files
  -f  Follow symbolic links
  -y  Store symbolic links
  -v  Verbose info
  -0  Store only
  -1  Compress faster
  -9  Compress better
  -k  Disk size in KB
  -z  Zip central directory
  -p  Encryption password
  -s  AES encryption
  -b  BZIP2 compression
  -m  LZMA compression
  -n  XZ compression
  -t  ZSTD compression

**Replay**

git clone https://github.com/zlib-ng/minizip-ng.git
cd minizip-ng/
CC="gcc -fsanitize=address" CXX="g++ -fsanitize=address" cmake -S . -B build -D MZ\_BUILD\_TESTS=ON
cmake --build build
./minizip -x -o poc1

**ASAN**

\-x -o /root/poc/minizip/poc1 
Archive /root/poc/minizip/poc1
=================================================================
==3028155==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d0000001df at pc 0x55555555d76e bp 0x7fffffffddf0 sp 0x7fffffffdde0
READ of size 1 at 0x60d0000001df thread T0
    #0 0x55555555d76d in mz\_path\_resolve (/root/test/minizip-ng/build/minizip+0x976d)
    #1 0x555555573c77 in mz\_zip\_reader\_save\_all (/root/test/minizip-ng/build/minizip+0x1fc77)
    #2 0x55555555af70 in minizip\_extract (/root/test/minizip-ng/build/minizip+0x6f70)
    #3 0x55555555c7ec in main (/root/test/minizip-ng/build/minizip+0x87ec)
    #4 0x7ffff73a9082 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x24082)
    #5 0x555555558aed in \_start (/root/test/minizip-ng/build/minizip+0x4aed)

0x60d0000001df is located 1 bytes to the left of 129-byte region \[0x60d0000001e0,0x60d000000261)
allocated by thread T0 here:
    #0 0x7ffff76a0808 in \_\_interceptor\_malloc ../../../../src/libsanitizer/asan/asan\_malloc\_linux.cc:144
    #1 0x55555557391b in mz\_zip\_reader\_save\_all (/root/test/minizip-ng/build/minizip+0x1f91b)
    #2 0x55555555af70 in minizip\_extract (/root/test/minizip-ng/build/minizip+0x6f70)
    #3 0x55555555c7ec in main (/root/test/minizip-ng/build/minizip+0x87ec)
    #4 0x7ffff73a9082 in \_\_libc\_start\_main (/lib/x86\_64-linux-gnu/libc.so.6+0x24082)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/root/test/minizip-ng/build/minizip+0x976d) in mz\_path\_resolve
Shadow bytes around the buggy address:
  0x0c1a7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1a7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1a7fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1a7fff8010: 00 00 00 00 00 00 00 00 01 fa fa fa fa fa fa fa
  0x0c1a7fff8020: fa fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\=>0x0c1a7fff8030: 00 00 01 fa fa fa fa fa fa fa fa\[fa\]00 00 00 00
  0x0c1a7fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 01 fa fa fa
  0x0c1a7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1a7fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1a7fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1a7fff8080: 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
\==3028155\==ABORTING

**POC**

https://github.com/Akane0721/POC/blob/f37d805631e0a15bea1f15b6e1edfb3246a2e0fc/minizip-ng/poc1

**Environment**

    Ubuntu 20.04
    Clang 10.0.0
    gcc 9.4.0
    

Where did poc1 come from? It is a badly corrupted zip file

minizip doesn't complain about it

    $ ./minizip -l poc1
    minizip-ng 4.0.1 - https://github.com/zlib-ng/minizip-ng
    ---------------------------------------------------
    -l poc1 
          Packed     Unpacked Ratio Method   Attribs Date     Time  CRC-32     Name
          ------     -------- ----- ------   ------- ----     ----  ------     ----
       805503117   2018794583   39% deflate         0 11-07-14 04:30 f0c14f39   l//../////////////0W/T/.�TU//�
    

But this is what unzip thinks about it

    $ unzip -l poc1
    Archive:  poc1
      End-of-central-directory signature not found.  Either this file is not
      a zipfile, or it constitutes one disk of a multi-part archive.  In the
      latter case the central directory and zipfile comment will be found on
      the last disk(s) of this archive.
    unzip:  cannot find zipfile directory in one of poc1 or
            poc1.zip, and cannot find poc1.ZIP, period.
    

same with 7z

    $ 7z l  ~/Downloads/poc1
    
    7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
    p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (506E3),ASM,AES-NI)
    
    Scanning the drive for archives:
    1 file, 253 bytes (1 KiB)      
    
    Listing archive: /home/paul/Downloads/poc1
    
    
    ERROR: /home/paul/Downloads/poc1 : Can not open the file as archive
    
    
    
    Errors: 1
    

the file appears to have a single local header that contains some crazy values.

    0000 0003 0004 50 4B 03 04 LOCAL HEADER #1       04034B50 (67324752)
    0004 0004 0001 14          Extract Zip Spec      14 (20) '2.0'
    0005 0005 0001 00          Extract OS            00 (0) 'MS-DOS'
    0006 0007 0002 02 ED       General Purpose Flag  ED02 (60674)
                               [Bits 1-2]            1 'Maximum Compression'
                               [Bit 11]              1 'Language Encoding'
                               [Bit 13]              1 'Encrypted Central Dir'
    0008 0009 0002 08 00       Compression Method    0008 (8) 'Deflated'
    000A 000D 0004 DC 23 67 45 Last Mod Time         456723DC (1164387292) 'Fri Nov  7 04:30:56 2014'
    000E 0011 0004 39 4F C1 F0 CRC                   F0C14F39 (4039200569)
    0012 0015 0004 8D 00 03 30 Compressed Length     3003008D (805503117)
    0016 0019 0004 57 5C 54 78 Uncompressed Length   78545C57 (2018794583)
    001A 001B 0002 78 00       Filename Length       0078 (120)
    001C 001D 0002 00 00       Extra Length          0000 (0)
    #
    # WARNING: Offset 0x1E: Could not decode 'utf8' Filename: utf8 "\x81" does not map to Unicode
    #
    001E 0095 0078 6C 2F 2F 2E Filename              'l//../////////////0W\T\.TU// Ô  ¿   nwGF¯ÀÑIí  Ü#gE9OÁð  CW\meri!kUTTUx   limer C   Èÿ mÊG
                   2E 2F 2F 2F                       U\nè ¶Í`eÒfÿ  ,8'
                   2F 2F 2F 2F
                   2F 2F 2F 2F
                   2F 2F 30 57
                   5C 54 5C 2E
                   81 54 55 2F
                   2F 01 D4 01
                   00 BF 00 00
                   00 6E 77 47
                   46 AF C0 95
                   D1 49 ED 08
                   00 DC 23 67
                   45 39 4F C1
                   F0 8D 00 03
                   43 57 5C 6D
                   65 72 69 21
                   6B 55 54 54
                   55 78 00 00
                   00 6C 69 6D
                   65 72 03 43
                   00 00 00 C8
                   FF 7F 8D 9E
                   E4 6D 8C CA
                   47 8D 00 00
                   00 8A 55 5C
                   98 BA 6E E8
                   03 B6 CD 60
                   65 D2 66 FF
                   7F 09 2C 38
    #
    # FATAL: Offset 0x96: file truncated while reading 'PAYLOAD'
    #        Expected 0x3003008D bytes, but only 0x67 available . 
    #
    

> Where did poc1 come from? It is a badly corrupted zip file
> 
> minizip doesn't complain about it
> 
>     $ ./minizip -l poc1
>     minizip-ng 4.0.1 - https://github.com/zlib-ng/minizip-ng
>     ---------------------------------------------------
>     -l poc1 
>           Packed     Unpacked Ratio Method   Attribs Date     Time  CRC-32     Name
>           ------     -------- ----- ------   ------- ----     ----  ------     ----
>        805503117   2018794583   39% deflate         0 11-07-14 04:30 f0c14f39   l//../////////////0W/T/.�TU//�
>     
> 
> But this is what unzip thinks about it
> 
>     $ unzip -l poc1
>     Archive:  poc1
>       End-of-central-directory signature not found.  Either this file is not
>       a zipfile, or it constitutes one disk of a multi-part archive.  In the
>       latter case the central directory and zipfile comment will be found on
>       the last disk(s) of this archive.
>     unzip:  cannot find zipfile directory in one of poc1 or
>             poc1.zip, and cannot find poc1.ZIP, period.
>     
> 
> same with 7z
> 
>     $ 7z l  ~/Downloads/poc1
>     
>     7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
>     p7zip Version 16.02 (locale=en_GB.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (506E3),ASM,AES-NI)
>     
>     Scanning the drive for archives:
>     1 file, 253 bytes (1 KiB)      
>     
>     Listing archive: /home/paul/Downloads/poc1
>     
>     
>     ERROR: /home/paul/Downloads/poc1 : Can not open the file as archive
>     
>     
>     
>     Errors: 1
>     
> 
> the file appears to have a single local header that contains some crazy values.
> 
>     0000 0003 0004 50 4B 03 04 LOCAL HEADER #1       04034B50 (67324752)
>     0004 0004 0001 14          Extract Zip Spec      14 (20) '2.0'
>     0005 0005 0001 00          Extract OS            00 (0) 'MS-DOS'
>     0006 0007 0002 02 ED       General Purpose Flag  ED02 (60674)
>                                [Bits 1-2]            1 'Maximum Compression'
>                                [Bit 11]              1 'Language Encoding'
>                                [Bit 13]              1 'Encrypted Central Dir'
>     0008 0009 0002 08 00       Compression Method    0008 (8) 'Deflated'
>     000A 000D 0004 DC 23 67 45 Last Mod Time         456723DC (1164387292) 'Fri Nov  7 04:30:56 2014'
>     000E 0011 0004 39 4F C1 F0 CRC                   F0C14F39 (4039200569)
>     0012 0015 0004 8D 00 03 30 Compressed Length     3003008D (805503117)
>     0016 0019 0004 57 5C 54 78 Uncompressed Length   78545C57 (2018794583)
>     001A 001B 0002 78 00       Filename Length       0078 (120)
>     001C 001D 0002 00 00       Extra Length          0000 (0)
>     #
>     # WARNING: Offset 0x1E: Could not decode 'utf8' Filename: utf8 "\x81" does not map to Unicode
>     #
>     001E 0095 0078 6C 2F 2F 2E Filename              'l//../////////////0W\T\.TU// Ô  ¿   nwGF¯ÀÑIí  Ü#gE9OÁð  CW\meri!kUTTUx   limer C   Èÿ mÊG
>                    2E 2F 2F 2F                       U\nè ¶Í`eÒfÿ  ,8'
>                    2F 2F 2F 2F
>                    2F 2F 2F 2F
>                    2F 2F 30 57
>                    5C 54 5C 2E
>                    81 54 55 2F
>                    2F 01 D4 01
>                    00 BF 00 00
>                    00 6E 77 47
>                    46 AF C0 95
>                    D1 49 ED 08
>                    00 DC 23 67
>                    45 39 4F C1
>                    F0 8D 00 03
>                    43 57 5C 6D
>                    65 72 69 21
>                    6B 55 54 54
>                    55 78 00 00
>                    00 6C 69 6D
>                    65 72 03 43
>                    00 00 00 C8
>                    FF 7F 8D 9E
>                    E4 6D 8C CA
>                    47 8D 00 00
>                    00 8A 55 5C
>                    98 BA 6E E8
>                    03 B6 CD 60
>                    65 D2 66 FF
>                    7F 09 2C 38
>     #
>     # FATAL: Offset 0x96: file truncated while reading 'PAYLOAD'
>     #        Expected 0x3003008D bytes, but only 0x67 available . 
>     #
>     

poc1 is a malformed zip file generated by fuzzer. I used the "-x" flag when testing and it came into a heap-buffer-overflow crash. So maybe you could give a proper prompt when using "-x" to extract malformed files like poc1?

> poc1 is a malformed zip file generated by fuzzer. I used the "-x" flag when testing and it came into a heap-buffer-overflow crash. So maybe you could give a proper prompt when using "-x" to extract malformed files like poc1?

ok.

Running without ASAN triggers a core. Never a good thing to do

    $ ./minizip -x  poc1
    minizip-ng 4.0.2 - https://github.com/zlib-ng/minizip-ng
    ---------------------------------------------------
    -x poc1 
    Archive poc1
    Extracting l//../////////////0W/T/.�TU//�
    double free or corruption (out)
    Aborted (core dumped)
    

When I build with ASAN I see the line numbers where the issue is triggered

    $ ./minizip -x -o poc1
    minizip-ng 4.0.2 - https://github.com/zlib-ng/minizip-ng
    ---------------------------------------------------
    -x -o poc1 
    Archive poc1
    =================================================================
    ==49454==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d0000001df at pc 0x55f2bdfcdfec bp 0x7ffd97501c40 sp 0x7ffd97501c30
    READ of size 1 at 0x60d0000001df thread T0
        #0 0x55f2bdfcdfeb in mz_path_resolve /home/paul/git/minizip-ng/mz_os.c:188
        #1 0x55f2bdfe577b in mz_zip_reader_save_all /home/paul/git/minizip-ng/mz_zip_rw.c:883
        #2 0x55f2bdfcb6f0 in minizip_extract /home/paul/git/minizip-ng/minizip.c:379
        #3 0x55f2bdfcd02c in main /home/paul/git/minizip-ng/minizip.c:654
        #4 0x7f874d2280cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
        #5 0x7f874d228188 in __libc_start_main_impl ../csu/libc-start.c:360
        #6 0x55f2bdfc9264 in _start (/home/paul/git/minizip-ng/build/minizip+0x7264) (BuildId: 576262a7c293cbb21845b25bd97a13cb33d9dd27)
    
    0x60d0000001df is located 1 bytes before 129-byte region [0x60d0000001e0,0x60d000000261)
    allocated by thread T0 here:
        #0 0x7f874dcddde0 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:85
        #1 0x55f2bdfe548d in mz_zip_reader_save_all /home/paul/git/minizip-ng/mz_zip_rw.c:861
        #2 0x55f2bdfcb6f0 in minizip_extract /home/paul/git/minizip-ng/minizip.c:379
        #3 0x55f2bdfcd02c in main /home/paul/git/minizip-ng/minizip.c:654
        #4 0x7f874d2280cf in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/paul/git/minizip-ng/mz_os.c:188 in mz_path_resolve
    Shadow bytes around the buggy address:
      0x60cfffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x60cfffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x60d000000000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x60d000000080: 00 00 00 00 00 00 00 00 01 fa fa fa fa fa fa fa
      0x60d000000100: fa fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x60d000000180: 00 00 01 fa fa fa fa fa fa fa fa[fa]00 00 00 00
      0x60d000000200: 00 00 00 00 00 00 00 00 00 00 00 00 01 fa fa fa
      0x60d000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x60d000000300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x60d000000380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x60d000000400: 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
    ==49454==ABORTING
    

The issue with this one is a filename of the form x/../fred. The code in mz_path_resolve tries to remove the .. by walking backwards to the preceding /. It wants to end up with the filename fred, but in this case there isn't a preceeding /, so it walks past the start of the buffer.

See test1.zip for small zip that reproduces the issue.

pmqs added a commit to pmqs/minizip-ng that referenced this issue

Nov 12, 2023

 pmqs mentioned this issue

Nov 12, 2023

nmoinvaz pushed a commit that referenced this issue

Nov 13, 2023

 

nmoinvaz added a commit that referenced this issue

Nov 13, 2023

Fixed in 4.0.3. Thank you!

CVE-2023-48106: Heap-buffer-overflow in mz_os.c:188 in mz_path_resolve · Issue #740 · zlib-ng/minizip-ng

An issue was discovered in Network Optix NxCloud before 23.1.0.40440. It was possible to add a fake VMS server to NxCloud by using the exact identification of a legitimate VMS server. As result, it was possible to retrieve authorization headers from legitimate users when the legitimate client connects to the fake VMS server.


**Details of the Vulnerability:**

*   **Vulnerability Name:** Server spoofing
    
*   **Affected Versions:** All VMS servers connected to Сloud
    
*   **Potential Impact:** If exploited, an attacker could perform a Man in the middle attack and hijack victim’s access to VMS server
    

**Action Taken:**

Upon discovering the vulnerability, our security team has: 

*   Promptly initiated a thorough investigation. 
    
*   Developed and tested a security patch to address the vulnerability. This patch will be deployed on **Fri, Sep 22th, 2023**.
    
*   Engaged with cybersecurity experts to enhance our security measures moving forward.
    

During our investigation, we have not found any evidence of this vulnerability being exploited yet. Vulnerability exploitation is relatively hard and demands multiple prerequisites, yet still we recommend performing certain actions.

**Recommended Action for Customers:**

*   **Immediate Action:** If you are using an affected version, we strongly urge you to change the VMS server owner’s (user “**admin**”) local password.
    
*   Perform users and permissions review.
    

**Support and Assistance:**

Should you encounter any issues or require assistance with the update, please reach out to our dedicated support team at support@networkoptix.com.

**Future Measures:**

We are constantly enhancing our security protocols and will continue to conduct regular security audits to prevent such incidents in the future. We also plan to expand our collaboration with third-party security experts to ensure our systems remain resilient against evolving cyber threats.

CVE-2023-6263: [vulnerability] 2023-09-21 - Server Spoofing - Cloud Health Status

A Cross-Site Request Forgery (CSRF) vulnerability in Sourcecodester Sticky Notes App Using PHP with Source Code v.1.0 allows a local attacker to obtain sensitive information via a crafted payload to add-note.php.

CVE-2023-47014: CVE-2023-47014-Sticky-Notes-App-Using-PHP-with-Source-Code-v1.0-CSRF-to-CORS/README.md at main · emirhanerdogu/CVE-2023-47014-Sticky-Notes-App-Using-PHP-with-Source-Code-v1.0-CSRF-to-CORS

Headwind MDM Web panel 5.22.1 is vulnerable to Incorrect Access Control due to a hard-coded JWT Secret.

Published CVE numbers:

*   https://www.cve.org/CVERecord?id=CVE-2023-47315
*   https://nvd.nist.gov/vuln/detail/CVE-2023-47315

Headwind MDM Web panel 5.22.1 is vulnerable to Incorrect Access Control due to a hard-coded JWT Secret.

The secret is hardcoded into the source code available to anyone on Git Hub. This secret is used to sign the application’s JWT token and verify the incoming user-supplied tokens.

Hardcoded JWT secret

Affected URL to the source code:

*   https://github.com/h-mdm/hmdm-server/blob/master/jwt/src/main/java/com/hmdm/security/jwt/TokenProvider.java
    

By exploiting this issue, attackers may craft their own JWT tokens on behalf of arbitrary users.

JWT token structure:

 {  
   "sub": "<username>",  
   "token": "<authToken>",  
   "exp": <when\_expired\_in\_unix\_timestamp\>  
 }

**Exploitation’s steps**

Authentication: Required (A low-level user access is enough to obtain the authToken of the targeted user)

*   Getting a sample JWT token by calling the API endpoint of the target web panel instance /rest/public/jwt/login (POST).
    
*   Modifying the JWT token by setting the _sub_ parameter to _admin_ and the parameter _token_ to the current _authToken_ of the admin user, then signing the JWT token with the hardcoded secret. Important note: due to an authorization issue affecting the web panel (CVE-2023-47316), the _authToken_ of other users can also be retrieved even by a low-level user by calling the /rest/private/users/all (GET) API endpoint.
    

Crafting a new JWT token

   

*   Putting the crafted JWT token into the Authorization header of the HTTP request targeting the victim’s H-MDM web panel:
    

Using the crafted JWT token

​

Tag

#git