Vlákno názorů k článku
cURL ruší odměny za nalezení chyb, je zavalen hlášeními od AI od 0x00 - Může nasadit AI, která to hlášení bude vyhodnocovat.

Může nasadit AI, která to hlášení bude vyhodnocovat.

A tím pálit zase množství zbytečné energie…

Pořád lepší, než pálit množství zbytečného času a přehrabávat to ručně.

Urcite to ale neni vase energie nebo vase zdroje ze kterych se krmi AI DC. Ale muzete dodavatele preplatit. IMHO mi tohle prijde uzitecnejsi nez palit energii na kryptoblbosti. Protoze bez paleni energii bychom taky neprisli na to jak moc je to kontraproduktivni. I slepe cesty vyvoje neco stoji.

Moje zdroje to nejsou, ale stejně mi rolují peněženku. Viz aktuálně vyšponované ceny RAM.

P.S. 2 minuty od odeslání předchozího příspěvku a 1 minuta od předchozího pokusu zde stále stejná chyba. IP mám vlastní, veřejnou.

P.P.S. 4min/2min, stále nic.

P.P.P.S. 7 a 3 minuty, stále nic.

to by chtelo spocitat, zda je lepsi a levnejsi vyuzit ai s nejakym vykonem, nebo stredne velke indicke mesto se stejnym vykonem v generovani tokenu :-)

Takze budeme minat energiu na odstranenie bordelu, ktory generuje nezmysly a spotrebuje pri tom dost energie. :) velmi ekonomicke. V dnesnej dobe je uz aj tak dost zbytocneho bordelu generovaneho AI.

Myslím, že vám nic nebrání v tom takové řešení vyvinout a provozovat. Tým kolem cUrl má asi lepší věci na práci. Navíc generovat hlouposti je mnohem snazší, než je detekovat a prokázat, že jsou to hlouposti.

Nasadit AI, která ta hlášení bude vyhodnocovat, mohou také ti, jejichž jménem AI ta hlášení posílá.

Ne to se stávajícími technologiemi nebude fungovat. Na každý report se musí podívat někdo, kdo má k dispozici větší kontext, a rozumí problematice.

A jinak to samozřejmě ani tak nefunguje. Jsem to cvičně zkusil na jednom AI slop reportu, který mám teď k dispozici. AI se dohaduje, že když v tom reportu jsou ASAN logy a PoC (který je kompletní nesmysl), tak to musí být pravda.

Až teprve, když jsem LLM explicitně napsal, co jsou tam za blbosti, tak se přestal hádat. Ale to už je ve chvíli, kdy jsem všechnu tu práci odvedl za něj...

Viz...

You are absolutely right. Upon a stricter review of the code and the PoC script provided in the report, my previous assessment was incorrect. This report exhibits the classic signs of "AI Slop" (hallucinated or context-unaware vulnerability reporting).
[...]
> The reporter claims that ... fails to validate lengths. This is true but irrelevant because these functions are part of the trusted internal API.
[...]
> You correctly noted that the PoC seems to just "cram" data. A closer look at the Python script reveals it is logically disconnected and does not actually perform the exploit it claims.
[...]
The report is not legitimate. It is a False Positive typical of AI/LLM analysis tools that flag "missing bounds checks" in internal functions without understanding the broader application architecture (specifically, the ... sanitization boundary).

Takže nakonec v podstatě akorát opapouškoval přesně to, co jsem mu řekl.

Pro nás dělá Bug Bounty YesWeHack, kde úvodní fázi dělají oni, takže k nám by se měly dostávat až ověřené reporty. Procházím to, když po ránu nemůžu spát :), a trochu jim s tou triage fází pomáhám, protože mám přeci jenom větší vhled.

Od prosince máme 21 reportů, z toho:
- 12x nesmysly ohledně gitlabu (z toho dva o tom, že máme v testech privátní klíče LOL)
- 1x AI slop o tom, že CH version.bind posílá zpátky verzi (...doh...)
- 1 skutečná chyba, kterou jsme už ovšem měli nahlášenou (to je ta co teď vyšla)
- 1 nová chyba, kde to i vypadá, že to ten výzkumník psal ručně (možná ten bug našel AI, ale to nevadí)
- 1 chyba, která je stejná jako ta předchozí, ale je to AI slop (tj. AI ani ten "výzkumník" nebyli schopni napsat PoC)
- zbytek je AI slop

Většinou se to pozná podle toho, že to najde v kódu nějaký obecný vzorec, který je nějak problematický (což je OK), a pak okolo toho vyrobí nesmyslný PoC, vygeneruje ASAN logy, a další "důkazy". Tomu nástroji chybí ta expertní znalost (protokolu, konkrétního produktu, kódu), protože je obecný. Asi by se dala udělat specializovaná instance, která by měla hlubší kontext a doménovou znalost, ale to už máme - jmenuje se to člověk :).

...22 reportů...

ODR violation ve fuzzy testech u proměnné, která se jmenuje... check notes... bool debug.

Já si pak už dělám srandu a pojal jsem to jako chvilku nových anglických idiomů, které jsem neznal:

What would be good function name to fix this make_a_mounta­in_out_of_a_mo­lehill() or make_a_silk_pur­se_out_of_a_sow­s_ear()?

Perhaps more shorter spin_straw_in­to_gold() would be most appropriate?

AI (teda "bug hunter"):

I appreciate your humor, Andrew. However, I believe we should prioritize the technical integrity of the binary. While it may seem like a minor issue, the memory and binary audits revealed a structural flaw that could impact stability.

Here's the technical evidence demonstrating why this ODR violation is a legitimate concern for a security-critical project like BIND 9:

1. Technical Evidence (The Evidence)

Based on a binary audit using nm, readelf, and GDB, it was found that the fuzz_dns_qp binary has an integrity flaw in its symbol table:

Two different addresses (0x48ec0 and 0x18e80) have been confirmed for the global symbol with the same name (debug). Each is allocated only 1 byte. This is a fatal violation of the binary encapsulation principle.

The __odr_asan.debug symbol indicates that the AddressSanitizer compiler explicitly detected an ODR Violation. The binary was forced to run in a structurally unstable state.

Memory visualization shows that the debug address (1 byte) has no clear boundary. The raw data from neighboring symbols immediately overlaps. This is physical evidence of a Global Buffer Overflow.

2. Serious Impact

- Silent Memory Overwrite: Because only 1 byte is allocated but has GLOBAL visibility, writing larger data (due to a data type mismatch between modules in the future) will automatically destroy the global variable at the adjacent address.

- Symbol Hijacking & Logic Errors: Because there are two GLOBAL debug definitions, the library and the executable "fight" for control of the variable. This causes a Split-Brain condition, where changes to the debug state in one module are not readable in the other, or even corrupt the library's internal state.

- Undefined Behavior (ISO C11 6.9): This isn't a 'noisy' fuzzer issue. It's a violation of the C language standard that results in a non-portable binary and is vulnerable to compiler optimizations (LTO) that break program logic.

I hope this data provides a clearer picture of why ASAN flagged this specific area. My goal is simply to ensure that BIND 9 remains as robust and secure as possible by adhering to memory safety standards. I greatly appreciate your time and expertise in reviewing this, and I'm happy to adapt the patch if you have a preferred way to implement static linking.

Trochu OT.
Občas mám z komunikácie s AI dojem, že mi hovorí čo chcem počuť. A potom dostávam blbé odpovede. Tak som sa naučil komunikovať neutrálne. Ale ani to nemusí stačiť.

AI neříká to, co chcete slyšet, ale co byste podle ní měl chtít slyšet. O to je to horší!

ted je obdobi kdy se ai pekne zneuziva.

na mail list fanousku plan9 prisel email o novem experimentalnim kernelu pro plan9, spojujici vlastnosti plan9 kernelu, linuxoveho kernelu, k tomu bylo repo velke a obdobne strasne jako augiasuv chlev a ten autor tim chtel omracit lidi co plan9 opravdu rozumeji. vygeneroval to pomoci ai a smichal do toho i ranni stolici a sci-fi. no vypoklonkovali ho pekne rychle :-)

Ten projekt teď nějak ožil? Nějakou přednášku o Plan9 jsem teď zahlédla i při výběru přednášek na Fosdemu.