Re: [Full-disclosure] ICQ 6 protocol bug?
valdis.kletni...@vt.edu wrote: On Sat, 14 Feb 2009 23:26:48 +0200, James Matthews said: ICQ is known to have a few remote bugs. I use meebo.com instead of a client due to these issues. At which point you're probably trading known bugs for unknown bugs. ;) Of course, this is a battle the user can't win. The other option is to toss the proprietary ICQ client and use some other open-source client like Pidgin - at which point you're trading known ICQ bugs for unknown Pidgin bugs. At that point, your best bet is to consider 2 things: 1) What client am I most likely to see actual attacks against? 2) What client am I the most worried about attacks? (Note the two don't have to be the same - widespread ICQ attacks may be more common, but maybe you worry more about getting hit with a Pidgin attack because it possibly means you're being targeted) Pidgin seems to spontaneously self combust without it being attacked. Which is just a little bit more disruptive. So there's the trade off: do i worry about attacks or worry about my conversation being randomly disrupted? But in summary, nobody seems to know of anything new, so I need to watch the icq traffic with wireshark to see what's what. At the very least, messages from unknown parties can be ignored and it seems to be the rendering(again!) that has caused problems. Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] ICQ 6 protocol bug?
For some time now I've seen ICQ receive messages, from unknown people, occassionally make the client core dump'. The messages are often gibberish - more like the ASCII characters from someone trying to make it execute something it shouldn't. My interpretation of this is unknown parties are trying to exploit a bug in ICQ6 (it may work on Win2k or Win98...) but I might be wrong. I need to fire up wireshark to see what actually get sent. Has anyone else seen this? Or have details on what the hack is? Google found some hits for old bugs, older than ICQ6 Darren -- Darren Reed darr...@reed.wattle.id.au ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris Devs Are Smoking Pot
To block nastygrams like this and others, you should be able to do this with ipfilter rules like this: echo '@0 block in quick all with short' | ipf -6f - and/or add said rule to the top of your ipf6.conf file. Unfortunately the exploit expects you to be using Linux, so I'm somewhat challenged to verify this at present. Darren -- Darren Reed darr...@reed.wattle.id.au ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris telnet vulnberability - how many on your network?
In some mail from Joe Shamblin, sie said: How about just uncommenting the following from /etc/default/login # If CONSOLE is set, root can only login on that device. # Comment this line out to allow remote login by root. # CONSOLE=/dev/console Not a fix to be sure, but at least prevents a remote login. This only controls access to the account known as root. I'll wager that there are other accounts you could use this to get access to (that you shouldn't be able to) which could lead to various sorts of security issues. Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Detecting local anomalies (fwd)
[originally sent by me to nmap-hackers] Can nmap tell when the response time of a packet from a host differs by a large amount with respect to the majority of packets and from that make any suggestions or conclusions? For example, if nmap were to get a response of some kind from a linux box that sent the packet up through libipq, wouldn't there by a rather large time difference for it? Another example might be if one packet matches a different local policy, say IPsec, and it gets tunnelled/encrypted/ something before the response being sent back. The reason this came to mind is that last week I hacked up some code to do port-knocking with IPFilter in a manner that to the casual observer will always look like every port is closed unless the right combination is hit and then only the last one is open. I was thinking this is pretty undetectable from a scanning point of view. Then for some reason I thought about the impact of the knocking ports sending packets up to user space before generating a negative reply and that this would be detectable at a packet level in the difference between the time it takes for normal replies to be returned vs these ones. I've since removed the need for the trip to user space just to generate the negative reply but it did get me thinking and I thought I'd share those thoughts :) Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: (ICMP attacks against TCP) (was Re: HPSBUX01137 SSRT5954
In some mail from Dana Hudes, sie said: you will find a range of MTU sizes in radio links of various sorts which is not just 802.11 but also cellular including GPRS CDMA and WCDMA. Now, in many instances there is a proxy between the mobile station and the public network. In fact I wrote a powerpoint presentation summarizing such a paper on transparent TCP proxy in WCDMA and its on my site http://www.networkengineer.biz (I took a course in wireless architecture). This website does nothing more than show ads if you are using mozilla. Please do better than that if you're posting to a public forum. In many instances, the traffic I've seen between base stations and mobile phones has a normal MTU. (I worked on software that handles wireless data.) Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: (ICMP attacks against TCP) (was Re: HPSBUX01137 SSRT5954
In some mail from Fernando Gont, sie said: At 07:25 p.m. 20/07/2005, Darren Reed wrote: In some mail from Fernando Gont, sie said: The IPv4 minimum MTU is 68, and not 576. If you blindly send packets larger than 68 with the DF bit set, in the case there's an intermmediate with an MTU lower that 576, the connection will stall. And I think you can safely say that if you see any packets trying to indicate that the MTU of a link is 68 then you should ignore it. Yes. But what about 296? ... I think it is reasonable to say anyone trying to advertise an MTU less than 576 has nefarious purposes in mind. There are still some radio links with MTUs of 296 bytes. Go search with googlepeople still actively use smaller MTUs. What do you do? Where do you draw the line in the sand? Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: ICMP-based blind performance-degrading attack
Ok, so you really think this is new... Go look in the bugtraq archives for 8 July 2001 and you might find an email like the one below. THere was a thread on this topic then. It would be nice if you included a referral or something in your IETF draft to my original work on this, 4 years ago. Unless you want to try and proclaim that discussion on bugtraq isn't public knowledge and your discoveries are somehow new. This is just one pointer to a start of the thread then... http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00124.html And the original email is included below, just in case. Good luck with your further research on IP security issues. Cheers, Darren Subject: Small TCP packets == very large overhead == DoS? To: bugtraq@securityfocus.com Date: Sun, 8 Jul 2001 01:47:21 +1000 (Australia/ACT) X-Mailer: ELM [version 2.5 PL1] Content-Length: 6209 Status: OR On a lan far far away, a rouge packet was heading towards a server, ready to start up a new storm ... [I was going to start this by saying years ago but well... that might be showing my age ;)] Anyway, down to business. If any of you have tested what happens to the ability of a box to perform well when it has a small MTU you will know that setting the MTY to (say) 56 on a diskless thing is a VERY VERY bad idea when NFS read/write packets are generally 8k in size. Do not try it on a NFS thing unless you plan to reboot it, ok ? Last time I did this was when I worked out you could fragment packets inside the TCP header and that lesson was enough for me ;_) Following on from this, it occurs to me that the problem with the above can possibly be reproduced with TCP. How ? That thing called maximum segment size. The problem? Well, the first is that there does not appear to be a minimum. The second is that it is negoiated by the caller, not callee. Did I hear someone say oh dear ? What's this mean? Well, if I connect to www.microsoft.com and set my MSS to 143 (say), they need to send me 11 packets for every one they would normally send me (with an MSS of 1436). Total output for them is 1876 bytes - a 30% increase. However, that's not the real problem. My experience is that hosts, especially PC's, have a lot of trouble handling *LOTS* of interrupts. To send 2k out via the network, it's no longer 2 packets but 20+ - a significant increase in the workload. A quick table (based on 20byte IP TCP header):: datalenmss packets total bytes bytes %increase 1436 1436 1 14760 1436 1024 2 15163% 1436768 2 15163% 1436512 3 15565% 1436256 6 1676 13% 1436128 12 1916 30% 1436 64 23 2356 69% 1436 32 45 3236 119% 1426 28 52 3516 238% (MTU = 68) 1436 16 90 5036 241% 1436 8 180 8636 485% 1436 11436 58876 3989% For Solaris, you can enforce a more sane minimum MSS than the install default (1) with ndd: ndd -set /dev/tcp tcp_mss_min 128 HP-UX 11.* is in the same basket as Solaris. *BSD have varying minimums well above 1 - NetBSD at 32, FreeBSD at 64. (OpenBSD's comment on this says 32 but the code says 64 - mmm, qwality!) Linux 2.4 is 88 I can't see anything in the registry or MSDN which says what it is for Windows. By experimentation, Win2000 appears to be 88, NT 4 appears to be 1 Do I need to mention any other OS ? :*) Nothing else besides Solaris seems to have anything close to a reasonable manner in which to tune the minimum value. What's most surprising is that there does not appear to be a documented minimum, just as there is no minimum MTU size for IP. If there is, please correct me. About the only bonus to this is that there does not appear to be an easy way to affect the MSS sent in the initial SYN packet. Oh, so how's this a potential denial of service attack? Generally, network efficiency comes through sending lots of large packets...but don't tell ATM folks that, of course :-) Does it work? *shrug* It is not easy to test...the only testing I could do (with NetBSD) was to use the TCP_MAXSEG setsockopt BUT this only affects the sending MSS (now what use is that ? :-), but in testing, changing it from the default 1460 to 1 caused number of packets to go from 9 to 2260 to write 1436 bytes of data to discard. To send 100 * 1436 from the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with an MSS of 1460. Of even more significance, one connection like this made almost no difference after the first run but running a second saw kernel CPU jump to 30% on an SS20/712 (I suspect there are some serious TCP tuning happening dynamically). The sending host was likewise afflicted with a signifcant CPU usage penalty
