I too see this problem with stunnel on a public-facing Ubuntu 18.04 server. In addition to the stack trace with debugging symbols that I provided earlier, I now have a packet capture of one of the TLS sessions that caused a crash.
I was lucky enough to catch the attacker in the act, and in addition to capturing packets on the wire, I was also logging TLS session premaster keys. I've injected the relevant ephemeral key material (*not* my server private key!) into the capture so that we can all see inside the TLS tunnel. I'm not a TLS expert, but nothing jumped out at me as being obviously malformed or exploitative in the TLS negotiation, though second opinions are very welcome. Looking inside the tunnel, the attacker appears to be trying to begin some sort of WordPress-based vulnerability test. Stunnel crashed before it could connect to the local service I have it in front of, so this HTTP GET request was never delivered downstream. For what it's worth, I'm not running WordPress, so that vulnerability scan would have come up empty anyway. Please let me know if there's any more information I can provide regarding this packet capture or my server configuration. ** Attachment added: "Capture of an attack that caused stunnel to crash" https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1847275/+attachment/5312290/+files/stunnel-crash-20191206145927.pcapng -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847275 Title: stunnel4: "INTERNAL ERROR: Bad magic at ssl.c, line 117" - DoS vulnerability To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1847275/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
