See the complaint on #4039. This doesn't fix that particular
issue (it's somewhat unrelated), but does solve around
a file parsing problem reported by @void-in
This module exploits a code injection in specially crafted environment
variables in Bash, specifically targeting dhclient network configuration
scripts through the HOSTNAME, DOMAINNAME, and URL DHCP options.
I used the protocol version from the record layer thinking I was using
the protocol version from the handshake. This commit fix this and uses
the protocol version from the handshake instead of from the record layer
as in https://gist.github.com/rcvalle/10335282, which is how it should
have been initially.
Thanks to @wvu-r7 for finding this out!
If encrypted, use the TLS_RSA_WITH_AES_128_CBC_SHA; otherwise, use the
first cipher suite sent by the client. This complements the last commit
and makes this module work with SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
when NEGOTIATE_TLS is not enabled (see
https://gist.github.com/rcvalle/10335282).
Use the protocol version sent by the client. This should be the latest
version supported by the client, which may also be the only acceptable.
This makes this module work with SSLv3, TLSv1.0, TLSv1.1, and TLSv1.2
when NEGOTIATE_TLS is not enabled (see
https://gist.github.com/rcvalle/10335282).
This commit changes how os_name and os_flavor are handled
for client-side exploits, matching recent changes to the
server-side exploits and scanner fingerprints.
This commit also updates the client-side fingerprinting to
take into account Windows 8.1 and IE 9, 10, and 11.
This does change some of the meaning of the required-ness of the
directories. Before, if you wanted to serve files, but not receive any,
you would just fail to set a OUTPUTPATH.
Now, since both are required, users are required to both send and
recieve. This seems okay, you can always just set two different
locations and point the one you don't want at /dev/null or something.
Otherwise you will tend to listen on your default ipv6 'any' address and
bound to udp6 port 69, assuming you haven't bothered to disable your
automatically-enabled ipv6 stack.
This is almost never correct.