Blocklists & Politics

Published: 2007-06-24
Last Updated: 2007-06-24 19:13:30 UTC
by Tony Carothers (Version: 1)
0 comment(s)

Philipp K from Vienna, Austria submitted this story, which I found very enlightening.  In it shows several things: The double-edged sword of blocklists, and just some of the politics of security.  Shown below is the submission, in its entirety.  Thank you Philipp for the interpretation!!


spamhaus.org put the IP range of the Austrian domain registry (nic.at) on their Spamhaus Block List [SBL] [1], even though they did not send spam messages. By doing that, they wanted to force nic.at to remove specific .at domains, whose subdomains reportedly host phishing sites. However nic.at did not comply as they claimed it would violate their general terms and conditions and it would also breach Austrian jurisdiction [2].

During the next few days different allegations occurred: It was claimed the subdomains where hacked (so the registration itself was all right) and nic.at referred spamhaus.org to the specific hosts’ and registrar as the specific problem was located there [3]. The number of offending pages varies from 15 [4] to hundreds [5], depending who (and also when) you asked. nic.at changed IP addresses only to be blocked a few hours later again. spamhaus.org refused to comment on its actions, making some issues even more confusing.

On the 21st spamhaus.org stopped the blocking [6] (only listing nic.at as supporter to "name and shame", still existing today [5]), as they reported all offending pages are gone. nic.at countered that they did not remove a single domain, but the specific hosts’ finally reacted (to who they had referred spamhaus.org right from the start).

Now the Internet Service Provider Austria [ISPA] is warning its members against spamhaus.org because of their "overreaction" [7].

This is just the short version; I have only described the most important developments for brevity.

Altogether this seems to be a big mess, being driven by different goals, points of view, and also ego. Using blocklists is a two edged sword (which has also been stated on isc.sans.org numerous times), but this story only makes me wonder for the sanity of the whole system.


[1] http://www.spamhaus.org/sbl/sbl.lasso?query=SBL55483

[2] http://www.heise.de/newsticker/meldung/91417

[3] http://futurezone.orf.at/it/stories/201402/

[4] http://www.heise.de/newsticker/meldung/91453

[5] http://www.heise.de/newsticker/meldung/91642

[6] http://www.spamhaus.org/organization/statement.lasso?ref=7

[7] http://futurezone.orf.at/it/stories/201924/

Keywords:
0 comment(s)

Apple Releases Patch for Cross-Site Scripting Vulnerability

Published: 2007-06-24
Last Updated: 2007-06-24 02:51:06 UTC
by Tony Carothers (Version: 1)
0 comment(s)

On Thursday Apple releases a patch which addresses a cross-site scripting vulnerability.  These can be downloaded from Apple Update or Apple Software Downloads.

From the Apple website

 

  • WebCore

    CVE-ID: CVE-2007-2401

    Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9 or later, Mac OS X Server v10.4.9 or later

    Impact: Visiting a malicious website may allow cross-site requests

    Description: An HTTP injection issue exists in XMLHttpRequest when serializing headers into an HTTP request. By enticing a user to visit a maliciously crafted web page, an attacker could conduct cross-site scripting attacks. This update addresses the issue by performing additional validation of header parameters. Credit to Richard Moore of Westpoint Ltd. for reporting this issue.

  • WebKit

    CVE-ID: CVE-2007-2399

    Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9 or later, Mac OS X Server v10.4.9 or later

    Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution

    Description: An invalid type conversion when rendering frame sets could lead to memory corruption. Visiting a maliciously crafted web page may lead to an unexpected application termination or arbitrary code execution. Credit to Rhys Kidd of Westnet for reporting this issue.

Keywords:
0 comment(s)

Comments


Diary Archives