Conectiva Updates wrote: > PACKAGE : ircd > SUMMARY : Local denial of service vulnerability Actually it's *remote* in the usual terminology on this list. Let me elaborate a bit because this shows an important point which is often neglected by advisory writers. Many of the interesting protocols (SMTP, DNS, NetNews, but also IRC) create an application-specific network on top of the IP network (or another kind of underlying transport network). If a protocol implementation has a security defect, there are two possibilities: o the application network can relay the attack o the application network does NOT relay the attack Let's look at typical SMTP server defects. A defect in the SMTP HELO argument parser can only be exploited by a server that passes mail to the defective server directly over SMTP (which means that you only have to patch your incoming mail relays to stop attacks from the Internet). However, a defective message header parser code can likely be exploited by anyone because it passes through mail relays. Patching your incoming relays is not very helpful in such cases, and you'll probably start with the final destination servers. (Since anybody can run an SMTP server and lure others into sending mail to it, defects in the server-to-server communcation are not less severe than other implementation errors.) For another example, let's suppose that there is a security defect in an IRC client. Attackers might be able to send requests to the broken client across the network, or it might be necessary that the server administrator has modified the server software specifically to exploit this defect. Obviously, defects of the first kind are far more severe because attackers can more easily fullfil the requirements. If we look at IRC servers, there are even more possibilities: directly connected clients, directly connected servers, any client, or any server on the network might be able carry out attacks. Usually, there is some kind of trust relationship between server operators, so the server-to-server exploits are considered less severe. If you need more examples, try to figure out the attack requirements for the last few BIND resolver vulnerabilities. It's a nice exercise. As you can see, the impact of a security defect can vary, depending on the ability of the application network to relay attacks. Therefore, it's extremely important to accurately describe the attack requirements in this context. Without such a description, system administrators cannot adequately plan for recovery from a vulnerbility because it's not clear which systems have to be addressed first. If you assume there aren't many administrators who can make use of this information, you are wrong. Not everyone who isn't able to immediately roll out a patch to tens of thousands of machines for which he is responsible in some way or other is a moron who doesn't care about security and, as a result, deserves anything what he receives. Unfortunately, you can't even buy the necessary information. For example, wgile Slammer was bringing down entire networks, all alerts stilled called for patching the servers, even though it was too late for that. A more helpful suggestion would have been to power-cycle entire floors with Slammer-infected hosts and non-critical systems (a technique at least one company applied as a measure of last resort). But I digress, so back to the vulnerability at hand. When IRC server developers talk about "local vulnerabilities" vs. "remote vulnerabilities", they mean the distinction given above (exploit over local connection vs. exploit over the IRC network). In the terminology with which most readers of this list are familiar, both attack vectors are "remote". "Local" attacks come from authenticated users or users with shell access. PS: irc2.10.3p4 fixed additional forced crash bugs besides the JOIN issue. The JOIN bug is just the only one that is/was actively exploited.
