Segmentation fault in coverting zip_date_time

[nyw0102]

Version

0.3.1

Description

There is an segmentation fault bug in the function 'days_in_year_month'. It seems the crash is cause by the unsafe function 'transmute' in 'fn convert_zip_date_time'

Current Behavior

ASAN detect segmentation fault in read the value at address 0x7ffffffedd1 in my machine.

 2. =================================================================
 3. ==3886353==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x55605c334b38 bp 0x7fffa7898ef0 sp 0x7fffa7898c00 T0)
 4. ==3886353==The signal is caused by a READ memory access.
 5. ==3886353==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
 6.     #0 0x55605c334b38  (/home/nyw0102/reporting/ouch/target/x86_64-unknown-linux-gnu/debug/ouch+0x4842b38) (BuildId: e857b83d9ea0b7d007a23678847a10293f146da8)
 7.     #1 0x55605866b3bc in ouch::archive::zip::convert_zip_date_time::ha3eeaa6f8a79920b /home/nyw0102/reporting/ouch/src/archive/zip.rs:219:16
 8.     #2 0x55605866d3ca in ouch::archive::zip::set_last_modified_time::h7cb74db5fe5fd548 /home/nyw0102/reporting/ouch/src/archive/zip.rs:238:25
 9.     #3 0x55605864c93e in ouch::archive::zip::unpack_archive::hdf165d25a54dbeaf /home/nyw0102/reporting/ouch/src/archive/zip.rs:74:17
10.     #4 0x5560586c1599 in ouch::commands::decompress_file::_$u7b$$u7b$closure$u7d$$u7d$::h4db9d6943371b2a8 /home/nyw0102/reporting/ouch/src/commands.rs:442:17
11.     #5 0x5560581be7f5 in core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h48f3f394f3b13b69 /home/nyw0102/s2fuzz/scripts/rust/library/core/src/ops/function.rs:248:5
12.     #6 0x5560585b26c8 in _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h3d268eed418e88a3 /home/nyw0102/s2fuzz/scripts/rust/library/alloc/src/boxed.rs:1934:9
13.     #7 0x5560586dd08e in ouch::commands::smart_unpack::h6fe64338a373a7b4 /home/nyw0102/reporting/ouch/src/commands.rs:673:17
14.     #8 0x5560586b1c2d in ouch::commands::decompress_file::h260f511819a88238 /home/nyw0102/reporting/ouch/src/commands.rs:439:59
15.     #9 0x5560586822c5 in ouch::commands::run::h5b77b8b9f47a27c5 /home/nyw0102/reporting/ouch/src/commands.rs:245:17
16.     #10 0x55605874b8fe in ouch::run::h106506763b692d59 /home/nyw0102/reporting/ouch/src/main.rs:32:5
17.     #11 0x55605874a40c in ouch::main::hf651c08f91475b62 /home/nyw0102/reporting/ouch/src/main.rs:24:23
18.     #12 0x5560581c2efa in core::ops::function::FnOnce::call_once::h153eaaf738196bab /home/nyw0102/s2fuzz/scripts/rust/library/core/src/ops/function.rs:248:5
19.     #13 0x556057fb1986 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h813b17f8ae687019 /home/nyw0102/s2fuzz/scripts/rust/library/std/src/rt.rs:145:18
20.     #14 0x55605c1575c4 in std::rt::lang_start_internal::h4a61547abbd425a7 (/home/nyw0102/reporting/ouch/target/x86_64-unknown-linux-gnu/debug/ouch+0x46655c4) (BuildId: e857b83d9ea0b7d007a23678847a10293f146da8)
21.     #15 0x55605876da7f in main (/home/nyw0102/reporting/ouch/target/x86_64-unknown-linux-gnu/debug/ouch+0xc7ba7f) (BuildId: e857b83d9ea0b7d007a23678847a10293f146da8)
22.  
23. AddressSanitizer can not provide additional info.
24. SUMMARY: AddressSanitizer: SEGV (/home/nyw0102/reporting/ouch/target/x86_64-unknown-linux-gnu/debug/ouch+0x4842b38) (BuildId: e857b83d9ea0b7d007a23678847a10293f146da8) 
25. ==3886353==ABORTING
26.  

Expected Behavior

Memory-safety code with no segmentation fault

Additional Information

I'll attach a bug report about this crash
ouch crash report.docx

[marcospb19]

Hey, that's an interesting find.

This only applies to 0.3.1 it's been two and a half years since that commit was added.

We don't have any unsafe blocks nowadays, so we aren't affected by this specific crash anymore.

The specific commit that added the unsafe block is this one.

Thanks for reporting tho! Please update to the newest version so you don't run into this crash anymore.

[nyw0102]

Thanks for the notification about the correct version! Now I can use "ouch" more safely and efficiently. I imagine other developers or users are also using or will use this version (0.3.1). I know RUSTSEC informs Rust users about bugs in crates to ensure safe usage. Is it okay to report this crash to RUSTSEC? Can I notify other users about this issue as well?

[marcospb19]

Thanks for the notification about the correct version! Now I can use "ouch" more safely and efficiently.

Huh, this sounds a lot like an LLM.

---

I don't think it is necessary to report it to RUSTSEC because Ouch is not a library and this version is old, but if you think this is a vector for ACE that will actually be used by attackers, I'd say you can do it.

This is a case where RUSTSEC will probably just grab attention of attackers instead of the people who are (possibly) vulnerable, cause in this case, there is no way our users will be notified about it. Ouch is not a dependency listed in Cargo.toml that GitHub checks in every project and generates an alert (like it happened recently for sqlx), so, would a RUSTSEC be useful?

I don't expect people to be using this tool in such outdated version.

[Shnatsel]

I believe a RustSec advisory can still be valuable for Linux distributions that track versions through the package manager, so they don't have to rely on Cargo.lock files, as well as anyone using cargo auditable.

For example, I see that Nix currently carries ouch v0.3.1. And Nix builds their entire archive with cargo auditable, so cargo audit bin can easily detect the issue.

So I am inclined to merge the RustSec advisory PR: rustsec/advisory-db#2084

[marcospb19]

Sorry for the late response.

@Shnatsel that's a great point, you changed my mind, thanks for elucidating.