Dobësi me rrezik të lartë në SiYuan: DNS rebinding anashkalon mbrojtjen SSRF

Një njoftim sigurie në GitHub Security Advisories përshkruan një dobësi me rrezik të lartë në SiYuan, të identifikuar si GHSA-x8gv-g2g3-65fj. Problemi prek mjetet e agjentit http_request dhe web_fetch dhe mund të lejojë kërkesa drejt shërbimeve të brendshme, duke anashkaluar kontrollin CheckHostSSRF.

Dobësia ka vlerësimin CVSS 8.2. Raporti i atribuohet studiuesit joysinleung dhe mban datën 13 gusht 2026. Materiali i furnizuar përmend rrugën e kodit të versionit v3.8.0, por nuk jep një interval të qartë të versioneve të prekura.

Si anashkalohet kontrolli

Problemi mbështetet te DNS rebinding dhe një mospërputhje kohore e tipit TOCTOU: adresa që kontrollohet përpara kërkesës nuk është domosdoshmërisht ajo me të cilën krijohet lidhja. Në provën e përshkruar, emri i njëjtë i hostit kthen fillimisht një IP që kontrolli e lejon dhe më pas adresën loopback 127.0.0.1 gjatë lidhjes.

Kështu, CheckHostSSRF miraton rezultatin e parë të zgjidhjes DNS, ndërsa kërkesa reale përfundon te një shërbim i brendshëm. Kjo krijon një dobësi SSRF, ku kërkesa e serverit drejtohet te një destinacion që mbrojtja synon ta bllokojë.

Demonstrimi përdori drejtpërdrejt funksionet util.HTTPRequest dhe util.WebFetch në rrugën e kodit v3.8.0. Përgjigjja e marrë tregoi se kërkesa kishte arritur te shërbimi i aksesueshëm vetëm nga brenda. Si kontroll krahasues, verifikimi i drejtpërdrejtë i adresës 127.0.0.1 u bllokua. Pra, problemi nuk është mungesa e plotë e filtrimit, por ndryshimi i destinacionit mes verifikimit dhe lidhjes.

Çfarë të dhënash mund të ekspozohen

Sipas njoftimit, një sulmues që mund të drejtojë agjentin mund të lexojë përgjigje nga shërbimet e brendshme dhe burime të arritshme nga pozicioni i rrjetit të kernel-it të SiYuan. Në mjedise cloud, kjo mund të përfshijë metadata të instancës dhe kredenciale të përkohshme IAM.

Shërbimi loopback në demonstrim shërben si zëvendësues për destinacione të brendshme, përfshirë adresën 169.254.169.254. Rreziku lidhet me qasjen që ka vetë kernel-i: kërkesa mund të arrijë burime që janë të disponueshme nga mjedisi ku ai ekzekutohet.

Dobësia është e arritshme kur mjetet http_request ose web_fetch janë të përdorshme. Njoftimi e përshkruan si të shfrytëzueshme në konfigurimin standard, si me SafeMode të aktivizuar, ashtu edhe të çaktivizuar. Ajo nuk varet nga konfigurimi Publish apo nga autentikimi.

Masat korrigjuese të propozuara

• Kontroll gjatë lidhjes: përdorimi i SSRFSafeDialer, ose i një kontrolli të përhershëm të IP-ve private, në transportin e të dy mjeteve, pavarësisht SafeMode.
• Fiksimi i rezultatit DNS: lidhja duhet të ripërdorë të njëjtën IP që kaloi kontrollin, në mënyrë që verifikimi dhe destinacioni përfundimtar të mos ndryshojnë.
• Ndryshim i klientit HTTP: zëvendësimi i httpclient.NewBrowserRequest() me një klient që përdor util.SSRFSafeDialer(timeout).DialContext.

Patch-i i propozuar është shkruar mbi kodin burimor v3.8.0 dhe është testuar për rrugën e demonstrimit në mjedisin e studiuesit. Megjithatë, ai nuk është përpiluar në një build të plotë të SiYuan; njoftimi kërkon që mirëmbajtësit ta verifikojnë në CI. Materiali i dhënë nuk konfirmon publikimin e një versioni të korrigjuar.

Burimi: GitHub Security Advisories