lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <bbfb8e05-6ac2-68b0-d703-099b0a8ce356@marcan.st> Date: Thu, 3 Aug 2017 04:28:46 +0900 From: "Hector Martin \"marcan\"" <marcan@...can.st> To: fulldisclosure@...lists.org Subject: [FD] [No CVE assigned] SMBLoris Windows/Samba SMB service DoS PoC PoC (runs under Linux): https://gist.github.com/marcan/6a2d14b0e3eaa5de1795a763fb58641e https://twitter.com/marcan42/status/892706927720808449 https://twitter.com/marcan42/status/892716247502082051 https://twitter.com/marcan42/status/892785957849645056 Original disclosure: https://smbloris.com/ There's a lot of talk about SMBLoris but nobody seems to have written a public efficient PoC yet, so I gave it a shot. A single instance takes down a fully patched Windows 10 Pro box with 8GiB of RAM in less than 10 seconds. I tried using Scapy initially, but it's dog slow, so I went with C. The PoC uses raw sockets to bypass the local TCP stack. It supports attacking from multiple source IPs (not requiring them to be bound to the adapter). There is rudimentary ARP support (gratuitous only, no real reply functionality). There is no throttling so some packets may be dropped. I haven't seen it completely deadlock a Windows machine yet (it keeps accepting connections and responding to pings), but it renders it completely unusable during the attack and several minutes after it ceases, and causes various kinds of persistent breakage (UI restarts, complete UI crashes, inability to start applications, I/O errors due to failure to allocate memory in the storage controller driver, etc.) where the only way to get the system behaving properly again is a hard reboot. On Samba/Linux it just causes typical recoverable Linux OOM behavior (modulo some processes getting OOM-killed) since smbd forks for each connection and consumes memory. This can be mitigated with 'max smb processes = 1000' in smb.conf. -- Hector Martin "marcan" (marcan@...can.st) Public Key: https://mrcn.st/pub _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Powered by blists - more mailing lists