I stopped using mmap for untrusted files

@calmstan

I disagree with the tone, not the bytes. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Do not mmap

Call-convention guess is not evidence. I reproduced it twice before I believed you. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Reject files over your cap by default. Silent huge allocs are bugs. Same class as the January thread, different binary.

I still keep a paper notebook for this kind of note. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Fuzz your own parser. If CI has no fuzzer, the intern is the fuzzer. I wrote a 12-line script and then threw it away. The listing was enough.

@ampx

I still keep a paper notebook for this kind of note. You wrote «mmap a hostile file, then a truncating writer on another handle». That is th

That is not what the listing shows. You are arguing a vibe. I disagree with the tone, not the bytes. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Fuzz your own parser. If CI has no fuzzer, the intern is the fuzzer. My note id for this: 61-07.

@hunt

Bookmarking this for the lab wiki. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another h

You are treating a checksum as a signature again. This is the writeup I wanted when I was stuck. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Do not mmap untrusted files. I will die on this. I wrote a 12-line script and then threw it away. The listing was enough.

Came back to this after a coffee. Still hold. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Reject files over your cap by default. Silent huge allocs are bugs. Took me 3 hours the first time.

@zenith

This is the kind of thread that should be a sticky and is not. You wrote «mmap a hostile file, then a truncating writer on another handle».

I am not moving this to DMs so you can yell. Stay on the class. I disagree with the tone, not the bytes. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Dry-run default on destructive flags. Lab tools delete files. Version in my shot: current lab snapshot, not last year's blog.

Did this on ARM64 last week — same shape, different pain. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Do not mmap untrusted files. I will die on this. I still have the snapshot named codi-97-pre.

Also: Dry-run default on destructive flags. Lab tools delete files.

I want the listing, not the decompiler story. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Caps on size and entry count are the feature. The parser is decoration. Can you quote the offset instead of the graph screenshot? I still have the snapshot named codi-97-pre.

@core

Did this on ARM64 last week — same shape, different pain. The load-bearing line: mmap a hostile file, then a truncating writer on another ha

Do not call people skids because they use Ghidra. This is the kind of thread that should be a sticky and is not. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Endian tests even if you 'only ship LE'. Hash of the public file, or are we arguing a shape? I still have the snapshot named codi-97-pre.

Bookmarking this for the lab wiki. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Caps on size and entry count are the feature. The parser is decoration. Pinned a comment at 0x140000688 in the listing.

Also: Reject files over your cap by default. Silent huge allocs are bugs.

I would have written the opposite conclusion a year ago. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Reject files over your cap by default. Silent huge allocs are bugs. I reproduced it on lab build 1216.

@juniorfx

This is the writeup I wanted when I was stuck. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. If yo

You skipped isolation and then asked why the box is dirty. That is on you. I tried the naive path first and wasted a morning. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Do not mmap untrusted files. I will die on this. Did page heap see it, or only the sanitizer? Same class as the October thread, different binary.

The screenshot is the useful part of the post. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Fuzz your own parser. If CI has no fuzzer, the intern is the fuzzer. Which build of the tool? I got burned mixing notes across versions. I will +rep a listing and −rep a vibe. That is the deal.

@bitsec

The screenshot is the useful part of the post. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Fuzz

I read the patch. You read a tweet. Those are not the same source. I would have written the opposite conclusion a year ago. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Dry-run default on destructive flags. Lab tools delete files. I reproduced it on lab build 1301.

@bryanwest

I would have written the opposite conclusion a year ago. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then

I disagree with the tone, not the bytes. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Do not mmap untrusted files. I will die on this. I wrote a 12-line script and then threw it away. The listing was enough.

@intel

This is the writeup I wanted when I was stuck. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sent

This is the writeup I wanted when I was stuck. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. If you intern, intern copies. Views into a temp will haunt you. I reproduced it on lab build 1210.

@edwardconnect

I still keep a paper notebook for this kind of note. You wrote «mmap a hostile file, then a truncating writer on another handle». That is th

I ran this on a licensed corpus binary. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Fuzz your own parser. If CI has no fuzzer, the intern is the fuzzer. Took me 5 hours the first time.

@fire

I ran this on a licensed corpus binary. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Fuzz your ow

Take the telegram pitch to the bin. Market listing or nothing. Bookmarking this for the lab wiki. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Caps on size and entry count are the feature. The parser is decoration. Same class as the January thread, different binary.

@deleconnect

I would have written the opposite conclusion a year ago. You wrote «mmap a hostile file, then a truncating writer on another handle». That i

You are describing a live target. Stop. Patched class only. I still keep a paper notebook for this kind of note. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. If you intern, intern copies. Views into a temp will haunt you. Pinned a comment at 0x140006cf4 in the listing.

@golfx

I want the listing, not the decompiler story. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer o

Quote the bytes or sit down. I disagree with the tone, not the bytes. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Checksums are not hashes. Stop keying maps with CRC32. I will +rep a listing and −rep a vibe. That is the deal.

@ledgr

Came back to this after a coffee. Still hold. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer o

I am not moving this to DMs so you can yell. Stay on the class. I still keep a paper notebook for this kind of note. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Need/take/remain. Every C parser I still write uses them. If anyone DMs me a zip I will not open it. Hash in-thread.

The screenshot is the useful part of the post. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Do not mmap untrusted files. I will die on this. I reproduced it on lab build 1174.

@n0va

The screenshot is the useful part of the post. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer

That is not what the listing shows. You are arguing a vibe. I ran this on a licensed corpus binary. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Implement encodings from the spec and a test vector, not from a blog post. I still have the snapshot named codi-97-pre.

@null

I ran this on a licensed corpus binary. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating wri

I reproduced it twice before I believed you. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Need/take/remain. Every C parser I still write uses them. Which build of the tool? I got burned mixing notes across versions. I will +rep a listing and −rep a vibe. That is the deal.

@oscar

I reproduced it twice before I believed you. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Need/ta

I read the patch. You read a tweet. Those are not the same source. Agreed on the class, not on the tool. On «I stopped using mmap for untrusted files»: mmap a hostile file, then a truncating writer on another handle. Endian tests even if you 'only ship LE'. Pinned a comment at 0x14000640e in the listing.

This matches a public n-day class from last patch Tuesday. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Fuzz your own parser. If CI has no fuzzer, the intern is the fuzzer. My note id for this: 61-30.

@resrch

This matches a public n-day class from last patch Tuesday. You wrote «mmap a hostile file, then a truncating writer on another handle». That

Call-convention guess is not evidence. I would have written the opposite conclusion a year ago. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Checksums are not hashes. Stop keying maps with CRC32. I wrote a 12-line script and then threw it away. The listing was enough.

Please keep the hashes and drop the mystery zips. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Do not mmap untrusted files. I will die on this. Version in my shot: current lab snapshot, not last year's blog.

This is the writeup I wanted when I was stuck. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Need/take/remain. Every C parser I still write uses them. I will +rep a listing and −rep a vibe. That is the deal.

@spryx

This is the writeup I wanted when I was stuck. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sent

You are treating a checksum as a signature again. I reproduced it twice before I believed you. «I stopped using mmap for untrusted files» — specifically mmap a hostile file, then a truncating writer on another handle. Dry-run default on destructive flags. Lab tools delete files. If anyone DMs me a zip I will not open it. Hash in-thread.

Bookmarking this for the lab wiki. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. If you intern, intern copies. Views into a temp will haunt you. I reproduced it on lab build 1085.

@urbanjay

Bookmarking this for the lab wiki. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. If you intern, in

You skipped isolation and then asked why the box is dirty. That is on you. I reproduced it twice before I believed you. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Do not mmap untrusted files. I will die on this. Did you snapshot before, or is this a restore-from-memory story? I still have the snapshot named codi-97-pre.

@vx-u

I reproduced it twice before I believed you. The load-bearing line: mmap a hostile file, then a truncating writer on another handle. Do not

This is the kind of thread that should be a sticky and is not. You wrote «mmap a hostile file, then a truncating writer on another handle». That is the sentence I keep. Caps on size and entry count are the feature. The parser is decoration. I wrote a 12-line script and then threw it away. The listing was enough.