I've read a paper some time ago explaining that this "vulnerability" (actually, it's there practically _by_design_ and it's called Direct Memory Access) can be used for forensics purposes.
You can access the RAM directly through the DMA controller (in the northbridge), so you're not using the CPU. The OS don't even notice that something is wrong and it cannot take any countermesure to stop it or to destroy compromising/sensitive data (think of "logical booby traps" designed to poweroff a machine - clearing the RAM - and/or erase the data from the disks at the first sign of trouble).
This is particularly useful when you're looking for any encryption key currently in use, because it will be probably stored somewhere in RAM, often in clear and can be easily recovered from the dump.
Actually, that's not a Gmail specific trick... it's standard email addressing as defined in the relevant RFCs (start with RFC2822 if you are interested). Lots of SMTP servers accepts and correctly parse addresses containing "+", basically routing the message to the mailbox matching the left part of the string - ie everything before the "+" sign, but keeping the whole string in the email headers. Try with your own SMTP service, not only with Gmail. Good chances it will work.
This is totally correct, but there are also other problems with stateless firewalls...
Let me explain what a stateful firewall does (not to you obviously, but I'm reading comments from lots of people that do not seem to fully understand the issue).
A stateful firewall can filter traffic not by just "blocking" some protocols or addresses/ports.
It can police traffic using the abstraction of "connections": you are able to tell it "allow NEW connections to this service, but not to that. And please let come in all traffic that pertains to already ESTABLISHED connections. Discard all INVALID - not NEW or ESTABLISHED - traffic" (yes, I'm taking the terms directly from linux's iptables/netfilter).
This is not simple as it seems... first, there are lots of problems with defining what a "connection" is just by looking at the traffic from the kernel's POV because is usually an application's (user space) work to make sense of all those bytes carried in the payload of TCP/UDP packets.
For plain old tcp session, like the ones used by SMTP or HTTP, this is easy: the protocol itself has the concept of "sessions" (every packet carries a "sequence number" that is used to identify the packet as part of a "session" - yes, this is a possible attack vector, and no, it's not _that_ easy to guess/brute force them. Not anymore). So, HTTP/SMTP and the like are EASILY firewalled and NATted.
But with ICMP or UDP? You have to do some smart tricks in order to implement the "connection" concept, for example: ok, we do not have session numbers, but if you send an ICMP echo request to an IP address, we should expect an ICMP echo reply to come back sooner or later from that same IP address, so here is your ICMP "session" (almost). Sending an ECHO request and receiving (or not) an ECHO reply is what actually happens when you use the "ping" command.
And beasts like FTP or SIP, H323, PPTP... the lot? Those nasty guys generally work by opening a TCP "control" connection, where protocol commands and responses are expected to travel... at some point during the conversation someone issues a command telling the other part(s) to expect a new connection on some other port and maybe with some other protocol... this command means something only to the high-level applications implementing these high-level protocols. It doesn't mean shit to the kernel, because this is not IP, TCP, UDP or ICMP: it's an higher level abstraction.
This is why you have to write special "helpers" for these protocols to bridge the gap and make things work: the "helpers" can intercept and understand the high level protocol commands and manipulate the kernel's notion of what low level traffic is RELATED to an already ESTABLISHED connection, because the kernel can't tell by itself.
In the case of FTP, the corresponding helper looks for the command "open new connection on port xxxrandomxxx for data transfer" (actually, the PORT and PASV commands) in the traffic travelling through the firewall, it figures that the important part is "port xxxrandomxxx" and then marks as "RELATED" traffic coming/going to port xxxrandomxxx (yes, "helpers" are another attack vector, and no... they are generally smarter than in my description, I am oversimplifying... (*)).
The same tricks are needed for some forms of NAT: specifically, the one when you have many hosts/PC on the "inside" and just one public routable address on the "outside" - Cisco calls this "PAT" - so the firewall needs to track "connections" to succesfully map traffic between external and internal hosts. Other forms of NAT includes the much simpler 1:1 (you have 'n' internal addresses and 'n' external addresses) and do not _require_ the tricks.
Having said all that...
Accepting ESTABLISHED tcp connections from port 80 (http) is a LOT different than just allowing generic tcp packets whose source is port 80 to come in, for example.
In the first case you're allowing only legal traffic that constitutes a response to your requests, as per th
Also relevant: http://www.dundi.com/
"DUNDi is a peer-to-peer system for locating Internet gateways to telephony services. Unlike traditional centralized services (such as the remarkably simple and concise ENUM standard), DUNDi is fully-distributed with no centralized authority whatsoever."
Slashdot Mirror
I've read a paper some time ago explaining that this "vulnerability" (actually, it's there practically _by_design_ and it's called Direct Memory Access) can be used for forensics purposes.
You can access the RAM directly through the DMA controller (in the northbridge), so you're not using the CPU. The OS don't even notice that something is wrong and it cannot take any countermesure to stop it or to destroy compromising/sensitive data (think of "logical booby traps" designed to poweroff a machine - clearing the RAM - and/or erase the data from the disks at the first sign of trouble).
This is particularly useful when you're looking for any encryption key currently in use, because it will be probably stored somewhere in RAM, often in clear and can be easily recovered from the dump.
Actually, that's not a Gmail specific trick... it's standard email addressing as defined in the relevant RFCs (start with RFC2822 if you are interested). Lots of SMTP servers accepts and correctly parse addresses containing "+", basically routing the message to the mailbox matching the left part of the string - ie everything before the "+" sign, but keeping the whole string in the email headers. Try with your own SMTP service, not only with Gmail. Good chances it will work.
This is totally correct, but there are also other problems with stateless firewalls...
Let me explain what a stateful firewall does (not to you obviously, but I'm reading comments from lots of people that do not seem to fully understand the issue).
A stateful firewall can filter traffic not by just "blocking" some protocols or addresses/ports.
It can police traffic using the abstraction of "connections": you are able to tell it "allow NEW connections to this service, but not to that. And please let come in all traffic that pertains to already ESTABLISHED connections. Discard all INVALID - not NEW or ESTABLISHED - traffic" (yes, I'm taking the terms directly from linux's iptables/netfilter).
This is not simple as it seems... first, there are lots of problems with defining what a "connection" is just by looking at the traffic from the kernel's POV because is usually an application's (user space) work to make sense of all those bytes carried in the payload of TCP/UDP packets.
For plain old tcp session, like the ones used by SMTP or HTTP, this is easy: the protocol itself has the concept of "sessions" (every packet carries a "sequence number" that is used to identify the packet as part of a "session" - yes, this is a possible attack vector, and no, it's not _that_ easy to guess/brute force them. Not anymore). So, HTTP/SMTP and the like are EASILY firewalled and NATted.
But with ICMP or UDP? You have to do some smart tricks in order to implement the "connection" concept, for example: ok, we do not have session numbers, but if you send an ICMP echo request to an IP address, we should expect an ICMP echo reply to come back sooner or later from that same IP address, so here is your ICMP "session" (almost). Sending an ECHO request and receiving (or not) an ECHO reply is what actually happens when you use the "ping" command.
And beasts like FTP or SIP, H323, PPTP... the lot? Those nasty guys generally work by opening a TCP "control" connection, where protocol commands and responses are expected to travel... at some point during the conversation someone issues a command telling the other part(s) to expect a new connection on some other port and maybe with some other protocol... this command means something only to the high-level applications implementing these high-level protocols. It doesn't mean shit to the kernel, because this is not IP, TCP, UDP or ICMP: it's an higher level abstraction.
This is why you have to write special "helpers" for these protocols to bridge the gap and make things work: the "helpers" can intercept and understand the high level protocol commands and manipulate the kernel's notion of what low level traffic is RELATED to an already ESTABLISHED connection, because the kernel can't tell by itself.
In the case of FTP, the corresponding helper looks for the command "open new connection on port xxxrandomxxx for data transfer" (actually, the PORT and PASV commands) in the traffic travelling through the firewall, it figures that the important part is "port xxxrandomxxx" and then marks as "RELATED" traffic coming/going to port xxxrandomxxx (yes, "helpers" are another attack vector, and no... they are generally smarter than in my description, I am oversimplifying... (*)).
The same tricks are needed for some forms of NAT: specifically, the one when you have many hosts/PC on the "inside" and just one public routable address on the "outside" - Cisco calls this "PAT" - so the firewall needs to track "connections" to succesfully map traffic between external and internal hosts. Other forms of NAT includes the much simpler 1:1 (you have 'n' internal addresses and 'n' external addresses) and do not _require_ the tricks.
Having said all that...
Accepting ESTABLISHED tcp connections from port 80 (http) is a LOT different than just allowing generic tcp packets whose source is port 80 to come in, for example.
In the first case you're allowing only legal traffic that constitutes a response to your requests, as per th
Also relevant: http://www.dundi.com/
"DUNDi is a peer-to-peer system for locating Internet gateways to telephony services. Unlike traditional centralized services (such as the remarkably simple and concise ENUM standard), DUNDi is fully-distributed with no centralized authority whatsoever."