(Sorry, this is not strictly DNS, but I would guess that this is the
cause of this shell-shock vector).
When looking at the code for libc I was most disappointed to see that
"/bin/sh" is hard coded for both "popen()" and "system()"
Where as I had previously assumed that the environment variable SHELL
could override this.
As "/bin/sh" is almost always a symlink to "/bin/bash", and many O/S
scripts assume this to be the case (i.e. use bash specific features,
without declaring "#!/bin/bash"), so simply making "/bin/sh" a link to
(say) "/bin/ash" is probably not an option.
So heads-up to any systems that use "popen()" or "system()" but have not
had bash upgraded - they may also have vulnerabilities.
IMHO, these two vectors mean shellshock will provide all sorts of
unexpected opportunities, until everybody is upgraded.
On 14/10/14 08:00, Stephane Bortzmeyer wrote:
Funny: an OS sends the result of some DNS queries to bash, allowing
the DNS operator to attack DNS clients with ShellShock:
http://packetstormsecurity.com/files/128650
What about an evil AS 112 operator attacking 168.192.in-addr.arpa
users?
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
