WiFi Device Driver Issues

Published: 2006-08-02. Last Updated: 2006-08-03 23:22:47 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Last weeks Intel Centrino issues where just the beginning. Today, Jon Ellch and David Maynor presented more wireless device driver issues at Blackhat. As a demo, they compromised a MacBook using one of the wireless device driver issues they discovered.

The highlights:
  • This is less of an OS problem, but a firmware/driver issue. While the demo was done on a Mac, it would have worked on other OS's as well.
  • Various wireless cards have problems, not just the once demoed at Blackhat.
  • You do not have to be associated with a wireless network in order to be exposed.
  • A firewall will not protect you.
What can you do:
  • Turn off the wireless card (and bluetooth while you are at it).
  • Watch for patches.
  • To prepare for any patches, learn what type of wireless card you have.
More details:

Washington Post "Securityfix" blog (Brian Krebs)
the video

Keywords:
0 comment(s)

Firefox 1.5.0.6 release imminent

Published: 2006-08-03. Last Updated: 2006-08-03 02:52:10 UTC
by Jim Clausing (Version: 2)
0 comment(s)
It appears that the Mozilla folks are about to release Firefox 1.5.0.6 (don't rush out and try to download it yet, the main Firefox page doesn't show it yet and for most of us, the automatic check will alert us to its availability).  No details at the moment on what this one fixes, but coming so quickly on the heals of 1.5.0.5, I would imagine that there must be some security implications.  We'll update this story as soon as the Release Notes are available.  And thank you to our ever faithful reader, Juha-Matti for alerting us to this.

Update 20:27 UTC:  If Bugzilla can be belived, all this update does is fix an issue with "mms://" and related multi-media URLs that have been broken in 1.5.0.5. Apparently, not all updates rushed out while a Blackhat conference is going on have a sinister reason :-).

Update 03:48 UTC: Firefox 1.5.0.6 is formally released.  The release notes confirm it fixes an issue with Windows Media.
Keywords:
0 comment(s)

named/bind error messages - solved

Published: 2006-08-02. Last Updated: 2006-08-02 18:41:18 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
ISC readers report a significant increase of "odd" error messages in their named/bind logs.

server named[18013]: dispatch 0x8face08: shutting down due to TCP receive error: [IP REMOVED]#53: connection reset.
named[8428]: dispatch 0x81eb2b0: shutting down due to TCP receive error: <unknown address, family 48830>: connection reset

Update 18:30 UTC:  It looks like we got the solution, or at least parts of it:
  • Some DNS servers of "secureserver.net" are apparently broken and sometimes return incomplete records. Two DNS servers in particular, 64.202.165.202 and 68.178.211.201, are implicated in the majority of the "TCP receive error" packet traces that we have received.
  • What happens is that "named" sends a UDP DNS query to one of the broken servers and receives a truncated UDP response. By nature of the DNS protocol, "named" re-tries the same query in TCP, which is answered by the broken servers with a rude "tcp reset" packet, which in turn again triggers "named" to write the above log line. This behaviour can be reproduced with "dig" as shown below:
    daniel@debian:$ dig whatever.net @68.178.211.201
    ;; Truncated, retrying in TCP mode.
    ;; communications error to 68.178.211.201#53: connection reset
  • Lookups against ISIPP's IADB spam / sender database seem to have ended up on the broken servers listed above from time to time, causing the "link" between receiving email and seeing the named log entries as reported by some readers
  • The IP address in the named log does not seem to have anything to do with the IP that causes the problem. I have no idea where this logged IP comes from, but seeing that some versions are printing "address unknown" instead of an IP, I suspect that this error print statement is broken in several (older?) Bind releases
A big thank you to all the readers who have volunteered their packet traces and time to help with this analysis!
Keywords:
0 comment(s)

Tip of the Day: Remove Default Route

Published: 2006-08-02. Last Updated: 2006-08-02 13:38:46 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
This tip comes from Mark Goudie:

Not having a default route in the router network is a great way to minimise the impact of malware on the corporate environment. This practice enforces that gateways are used for all external communications.

Advantages

  1. Enforces the use of proxy gateways for external communications.
  2. Malicious packets can be dropped or sent to a centralised server for analysis.
  3. Reduces the potential impact of misconfigured software through enforcing no internet connectivity.
  4. Makes malware infection easy to spot (if analysing all dropped packets).
I'd recommend implementing this with a split DNS to increase the difficulty of malware "phoning home" as the internal network cannot resolve external addresses. The DNS server could be configured to log all unresolved addresses for further malware indication.

Note that the above tip does not ask you to remove the default route off your end systems (user workstations) - chances are that many services needed in a corporate environment (like financial news feeds) will need to have a default route on the workstation. But if, in your network core, you can get away with only advertising and routing those external networks that are actually needed, you have made a huge step to secure your network. As indicated above, the newly un-used "default route" should then be made to point to a "darknet" where you have nothing except logging and packet collection capability.

Keywords: ToD
0 comment(s)

Comments

Login here to join the discussion.


Diary Archives