I found that a crafted file is able to crash qlop. To see the out of bounds error you need to compile it with -fsanitize=address. I will attach the crafted file and the output of ASan.
Created attachment 423974 [details] crafted-file.log
Created attachment 423976 [details] ASan output
This is reproducible with all versions actually in our main tree, so 0.56 and 0.60 @SECURITY: I'm waiting your feedback to proceed to ask a CVE ID for this issue. Thanks.
Created attachment 423978 [details] crash.log Reattached as text/plain.
(In reply to Agostino Sarubbo from comment #4) > Created attachment 423978 [details] > crash.log > > Reattached as text/plain. I'm unable to have the file attached in the right way via bugzilla. The crafted file is available here: http://dev.gentoo.org/~ago/qlop-crash-oob.log
there's no point in hiding this bug. open it up.
(In reply to SpanKY from comment #6) > there's no point in hiding this bug. open it up. This is standard policy for security auditing: "When you find a vulnerability, you should write a vulnerability description and submit it for peer-review as a new security bug (with "Gentoo Security" as product and "Auditing" as component, restricted to Gentoo Security). Other auditors (and security team members) will double-check what you found, ensure that it is indeed a bug with a security impact. " https://wiki.gentoo.org/wiki/Project:Auditing
(In reply to Kristian Fiskerstrand from comment #7) this bug is irrelevant in the wider world. people aren't running qlop manually on specially crafted files. the impact is 0. it is however making it a pain for me to look into it. if you want me to look into it, open the bug. otherwise i won't bother.
(In reply to SpanKY from comment #8) > (In reply to Kristian Fiskerstrand from comment #7) > > this bug is irrelevant in the wider world. people aren't running qlop > manually on specially crafted files. the impact is 0. it is however making > it a pain for me to look into it. Fair enough, opening
Comment on attachment 423974 [details] crafted-file.log this file works fine to reproduce
the crash is due to a truncated line, so we end up trying to read 2 bytes beyond what is valid. even then, we're talking about reading beyond the buffer. we do a single byte write when we see 'completed emerge' in that garbage buffer, but it's only to reset a space (0x20) byte to NUL (0x00). so the chance of exploit is extremely low if non-existent. you'd have to do quite a lot of heap grooming first. fixed by: https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=7aff0263204d80304108dbe4f0061f44ed8f189f in terms of versions, it's probably been this way "forever", and not a recent bug.
0.61 in the tree now https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5ba4a518a1fc671562fda1e57193e73498095bd
(In reply to SpanKY from comment #12) > 0.61 in the tree now > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=e5ba4a518a1fc671562fda1e57193e73498095bd Thanks! Is this ok to go stable? I agree with the no impact bit, though. Therefore [noglsa stable?].
0.62 is fine to stable now
@arches, please stabilize: =app-portage/portage-utils-0.62
Stable for HPPA PPC64.
arm stable
amd64 stable
x86 stable
alpha stable
done all the rest now
