The first report is the following:
> ## IU-KRB-001: Kerberos AUTH Fixed-Buffer Overflow
>
> Severity: High
>
> Affected code: `libtelnet/kerberos5.c::Data()`.
>
> `Data()` builds TELNET AUTH subnegotiation packets into fixed global storage
> (`str_data[2048]`) and appends Kerberos blobs without bounding the length.
> Oversized AP-REQ, mutual-auth, or forwarded-credential data can overrun the
> buffer before authentication completes.
>
> Reproduction:
>
> ```bash
> clang -fsanitize=address -g cve-kerberos/poc_kerberos5_data_overflow.c \
> -o cve-kerberos/poc_kerberos5_data_overflow
> ASAN_OPTIONS=detect_leaks=0 ./cve-kerberos/poc_kerberos5_data_overflow
> ```
>
> Network-level maintainer PoC:
>
> ```bash
> python3 cve-kerberos/PoC.py --mode server --host 127.0.0.1 --port 2323
> ```
Were you able to run this against an active telnetd server and trigger
ASAN?
>From my previous experience, having an LLM extract snippets of code into
a standalone C file and prove it is "vulnerable" means the LLM will copy
it incorrectly and/or call it with invalid arguments. Therefore, I did
not look much at all at poc_kerberos5_data_overflow.c.
I am very confused by the PoC.py script, since it doesn't appear to
actually run anything against a telnetd server? It just compiles some
similar C code to poc_kerberos5_data_overflow.c if the following
condition is met:
if args.mode == "rce-suggest":
return run_rce_suggest_mode(args)
Otherwise, it opens a listening socket and runs commands against it
without actually interacting with a telnetd server. Am I
misunderstanding something?
The second report is the following:
> ### 02-ftpd-yylex
>
> Finding: `ftpd/ftpcmd.y::yylex()` pre-auth off-by-one global OOB read/write.
>
> Files:
>
> - `poc_ftpd_yylex_cbuf_oob.py`
> - `poc_ftpd_yylex_cbuf_oob.log`
> - `asan_ftpd_yylex_cbuf_oob.log`
The script `poc_ftpd_yylex_cbuf_oob.py` is more reasonable. However, it
is still 200 lines of code that require my reading and understanding
before running. It could easily be simplified to this:
$ cat ~/main.py
import socket
HOST = "127.0.0.1"
PORT = 21
with socket.create_connection((HOST, PORT)) as s:
print(s.recv(4096).decode(errors="replace"))
s.sendall((b"NOOP" + (b"A" * 506)) * 2)
print(s.recv(4096).decode(errors="replace"))
Changing the size of the payload does not change the result. ASAN does
not get triggered and in Wireshark I see the following returned:
'NOOPAAA[...]': syntax error
I will try to take a look at the other 4 issues as well, but I feel that
this method of reporting vulnerabilities is very inefficient. These
scripts are much longer than necessary and very tailored to your
environment, e.g., hardcoded path names, depending on a special lldb
command. It makes it very difficult for me to reproduce. When the issues
do not reproduce, I need to question whether the report itself was bogus
or if I messed up the script in the process of making it usable in my
environment.
Are you able to send simple scripts that simply send a request to an
already running server without doing fancy things like parsing ASAN logs
for line numbers or running lldb in your environment? You can send them
to [email protected] if so.
I have dealt with LLMs hallucinating fairly convincing stack traces/GDB
before [1] [2]. Given the second report not reproducing, I am obviously
a bit skeptical of the rest.
Collin
[1] https://nvd.nist.gov/vuln/detail/CVE-2025-8733
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-8734
