for the details, read this report thanks https://github.com/N1nEmAn/wp/
So, we do: ... import gdb gdb.selected_inferior().read_memory(0, 18446744073709551615) ... and get a virtual memory exhausted error.
i love u man. I am a college student, and this is the first binary vulnerability in my life that has been recognized. -------- Original Message -------- 2024/4/11 上午4:04，vries at gcc dot gnu.org <sourceware-bugzilla@sourceware.org>，来信： > https://sourceware.org/bugzilla/show_bug.cgi?id=31631 > > Tom de Vries <vries at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |vries at gcc dot gnu.org > > --- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> --- > So, we do: > ... > import gdb > gdb.selected_inferior().read_memory(0, 18446744073709551615) > ... > and get a virtual memory exhausted error. > > -- > You are receiving this mail because: > You reported the bug. > You are on the CC list for the bug.
(In reply to Tom de Vries from comment #1) > So, we do: > ... > import gdb > gdb.selected_inferior().read_memory(0, 18446744073709551615) > ... > and get a virtual memory exhausted error. i think we can fix the python code of gdb, and add a check for the number if valid.
Created attachment 15459 [details] poc
Looks like a python-specific dup of PR17611. https://sourceware.org/pipermail/gdb-patches/2024-April/208019.html
> just run gdb and source the poc can make the memory corrupt/exhausted I'm not sure where you see memory corruption. I'm updating $subject to make the failure mode more clear.
(In reply to Tom de Vries from comment #6) > > just run gdb and source the poc can make the memory corrupt/exhausted > > I'm not sure where you see memory corruption. > > I'm updating $subject to make the failure mode more clear. you are right. sorry for my unclear descreption.
(In reply to N1nEmAn from comment #7) > (In reply to Tom de Vries from comment #6) > > > just run gdb and source the poc can make the memory corrupt/exhausted > > > > I'm not sure where you see memory corruption. > > > > I'm updating $subject to make the failure mode more clear. > > you are right. sorry for my unclear descreption. No problem, thanks for reporting this PR.
(In reply to Tom de Vries from comment #8) > (In reply to N1nEmAn from comment #7) > > (In reply to Tom de Vries from comment #6) > > > > just run gdb and source the poc can make the memory corrupt/exhausted > > > > > > I'm not sure where you see memory corruption. > > > > > > I'm updating $subject to make the failure mode more clear. > > > > you are right. sorry for my unclear descreption. > > No problem, thanks for reporting this PR. Thank you for your recognition. We look forward to your team's resolution of this issue. Additionally, I have a question. Can we apply for a CVE for this vulnerability through MITRE? Or is there another process? I didn't see Sourceware on the CNA list, but I only saw Glibc.
(In reply to N1nEmAn from comment #9) > (In reply to Tom de Vries from comment #8) > > (In reply to N1nEmAn from comment #7) > > > (In reply to Tom de Vries from comment #6) > > > > > just run gdb and source the poc can make the memory corrupt/exhausted > > > > > > > > I'm not sure where you see memory corruption. > > > > > > > > I'm updating $subject to make the failure mode more clear. > > > > > > you are right. sorry for my unclear descreption. > > > > No problem, thanks for reporting this PR. > > Thank you for your recognition. We look forward to your team's resolution of > this issue. > Additionally, I have a question. Can we apply for a CVE for this > vulnerability through MITRE? Or is there another process? I didn't see > Sourceware on the CNA list, but I only saw Glibc. AFAIU, there's no vulnerability here, just a usability issue.
(In reply to Tom de Vries from comment #10) > (In reply to N1nEmAn from comment #9) > > (In reply to Tom de Vries from comment #8) > > > (In reply to N1nEmAn from comment #7) > > > > (In reply to Tom de Vries from comment #6) > > > > > > just run gdb and source the poc can make the memory corrupt/exhausted > > > > > > > > > > I'm not sure where you see memory corruption. > > > > > > > > > > I'm updating $subject to make the failure mode more clear. > > > > > > > > you are right. sorry for my unclear descreption. > > > > > > No problem, thanks for reporting this PR. > > > > Thank you for your recognition. We look forward to your team's resolution of > > this issue. > > Additionally, I have a question. Can we apply for a CVE for this > > vulnerability through MITRE? Or is there another process? I didn't see > > Sourceware on the CNA list, but I only saw Glibc. > > AFAIU, there's no vulnerability here, just a usability issue. However, I believe that if it is present in pwndbg or any other code that could exist in gdbinit, it could potentially lead to a local denial-of-service attack.
*** Bug 31630 has been marked as a duplicate of this bug. ***
For the record, I think this is not a vulnerability according to the soon-to-be-landed security policy. See https://sourceware.org/pipermail/gdb-patches/2024-April/207917.html So, don't file a CVE. To my mind it's not even really a gdb bug, more like "don't do that".
(In reply to Tom Tromey from comment #13) > For the record, I think this is not a vulnerability > according to the soon-to-be-landed security policy. > > See https://sourceware.org/pipermail/gdb-patches/2024-April/207917.html > > So, don't file a CVE. > > To my mind it's not even really a gdb bug, more like > "don't do that". ok fine. i see. thanks
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=06e967dbc9b75a4a3c1b15b54360cf1abbf9c2bd commit 06e967dbc9b75a4a3c1b15b54360cf1abbf9c2bd Author: Tom de Vries <tdevries@suse.de> Date: Tue Apr 16 15:53:47 2024 +0200 [gdb/python] Throw MemoryError in inferior.read_memory if malloc fails PR python/31631 reports a gdb internal error when doing: ... (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) utils.c:709: internal-error: virtual memory exhausted. A problem internal to GDB has been detected, further debugging may prove unreliable. ... Fix this by throwing a python MemoryError, such that we have instead: ... (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) Python Exception <class 'MemoryError'>: Error occurred in Python. (gdb) ... Likewise for DAP. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631
Fixed.