Re: ID10T out of office responders (was Re: Yahoo DMARC breakage)
So Suppose I configure my email to send a Thanks, we have received your email, we will reply shortly in office hours.. Whats the Holy Headers so even poorly configured servers don't cause a AutoReply Storm? Googling, I found Precedence, X-Auto-Response-Suppress,..? For something like this, normally I would scan lots of opensource projects in www.google.com/codesearch (so I can learn from the projects with a large number of hours in production) , but seems down at the moment. -- -- ℱin del ℳensaje.
Re: ID10T out of office responders
On 4/11/2014 2:16 AM, Tei wrote: So Suppose I configure my email to send a Thanks, we have received your email, we will reply shortly in office hours.. Whats the Holy Headers so even poorly configured servers don't cause a AutoReply Storm? Googling, I found Precedence, X-Auto-Response-Suppress,..? For something like this, normally I would scan lots of opensource projects in www.google.com/codesearch (so I can learn from the projects with a large number of hours in production) , but seems down at the moment. Any device or process that uses information from the infinitely forgeable email headers is a process or device that can be subverted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: ID10T out of office responders
My experience shows that when things go wrong there is usually an amplified feedback loop between your mail server and the remote, so ensure that any header you set is one that you drop too. This is also why the mighty no-reply@ was thought up, which simply drops all mail. It might be crude, but it's effective. D. -- Excuse my brevity, I'm using a mobile device On Apr 11, 2014 9:30 AM, Larry Sheldon larryshel...@cox.net wrote: On 4/11/2014 2:16 AM, Tei wrote: So Suppose I configure my email to send a Thanks, we have received your email, we will reply shortly in office hours.. Whats the Holy Headers so even poorly configured servers don't cause a AutoReply Storm? Googling, I found Precedence, X-Auto-Response-Suppress,..? For something like this, normally I would scan lots of opensource projects in www.google.com/codesearch (so I can learn from the projects with a large number of hours in production) , but seems down at the moment. Any device or process that uses information from the infinitely forgeable email headers is a process or device that can be subverted. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: ID10T out of office responders (was Re: Yahoo DMARC breakage)
On Fri, 11 Apr 2014, Tei wrote:
Suppose I configure my email to send a Thanks, we have received your
email, we will reply shortly in office hours.. Whats the Holy Headers
so even poorly configured servers don't cause a AutoReply Storm?
Googling, I found Precedence, X-Auto-Response-Suppress,..? For
something like this, normally I would scan lots of opensource projects
in www.google.com/codesearch (so I can learn from the projects with
a large number of hours in production) , but seems down at the
moment.
If that's what you want to do, then setting one or more of these may help:
Auto-submitted: auto-generated
X-Auto-Response-Suppress: OOF
Precendence: bulk
(Other values of the last two are possible).
RFC3834 is background reading and references Auto-submitted:.
X-Auto-Response-Suppress: is used by MS Exchange/Outlook.
But if those servers really are poorly configured, there's no guarantee
they will honour any of those anyway.
If you want more control for yourself, you need to filter the return
messages out. I do this in Exim to identify automatically generated
email to be thrown away in some circumstances:
condition = ${if or { \
{ match {$h_precedence:} {(?i)junk|bulk|list} } \
{ eq {$sender_address} {} } \
{ def:header_X-Cron-Env: } \
{ def:header_Auto-Submitted: } \
{ def:header_List-Id: } \
{ def:header_List-Help: } \
{ def:header_List-Unsubscribe: } \
{ def:header_List-Subscribe: } \
{ def:header_List-Owner: } \
{ def:header_List-Post: } \
{ def:header_List-Archive: } \
{ def:header_Autorespond: } \
{ def:header_X-Autoresponse: } \
{ def:header_X-Autoreply-From: } \
{ def:header_X-eBay-MailTracker: } \
{ def:header_X-MaxCode-Template: } \
{ match {$h_X-Auto-Response-Suppress: } {OOF} } \
{ match {$h_X-OS:} {HP Onboard Administrator} } \
{ match {$h_X-MimeOLE:} {\N^Produced By phpBB2$\N} } \
{ match {$h_Subject:} {\N^Yahoo! Auto Response$\N} } \
{ match {$h_Subject:} {\N^ezmlm warning$\N} } \
{ match {$h_X-FC-MachineGenerated:} {true} } \
{ match {$h_X-Spam-Flag:} {\N^yes\N} } \
{ match {$message_body} {\N^Your \cron\ job on\N} } \
{ match {$h_Subject:} {\N^Out of Office\N} } \
{ match {$h_Subject:} {\N^Auto-Reply:\N} } \
{ match {$h_Subject:} {\N^Autoresponse:\N} } \
{ match {$h_Subject:} {\N(Auto Reply)$\N} } \
{ match {$h_Subject:} {\N(Out of Office)$\N} } \
{ match {$h_Subject:} {\Nis out of the office.$\N} } \
{ match {$h_From:} {\N(via the vacation program)\N } } \
{ ! match {$header_To: $header_CC: $header_Bcc: \
$header_Resent-To: $header_Resent-Cc: $header_Resent-Bcc:} \
} \
} {no} {yes} \
}
(I have not reviewed this for a very long time). Be careful.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.
Re: Yahoo DMARC breakage
On Thu, Apr 10, 2014 at 03:22:24PM -0400, Kee Hinckley wrote: I suspect they looked at the amount of spam they could stop [...] Which is, to a very good first approximation, zero. Nearly all (at least 99% and likely quite a bit more) of the spam [as observed by my numerous spamtraps] that purports to originate from Yahoo really *does* originate from Yahoo. All that I have to do to verify that is to look at the originating host -- that is, it's not necessary to check DMARC or anything else. There are several reasons for this. First, Yahoo has done an absolutely miserable job of outbound abuse control. For over a decade. Second, they've done a correspondingly miserable job of handling abuse reports, so even when one of their victims is kind and generous enough to do their work for them and tell them that they have a problem...they don't pay attention and they don't take any action. (Or they fire back a clueless boilerplate denial that it was their user on their host on their network...even though it was all three.) Also for over a decade. Third, why would any spammer forge a @yahoo.com address when it's easy enough to buy hijacked accounts by the bucketful -- or to use any of the usual exploits to go get some? Fourth, at least some spammers seem to have caught on that Yahoo isn't *worth* forging: it's a toxic cesspool because the people running it have allowed it to be become one. So let's not pretend that this has anything to do with stopping spam. If Yahoo actually wanted to do something about spam, they could have done that years and years ago simply by *paying attention* to what was going on inside their own operation. ---rsk
Heartbleed Bug Found in Cisco Routers, Juniper Gear
http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen
Re: Heartbleed Bug Found in Cisco Routers, Juniper Gear
Slightly sensationalistic article, tends to imply that heartbleed will allow you to capture data-plane traffic on any piece of Cisco/Juniper kit. Either way, as I've said before, if you're exposing *any* management interfaces, be is ssh,netconf or https to the internet in general, you've got bigger issues than just heartbleed. VPN, on the other hand, is a totally different world of pain for this issue. /ruairi On 11 April 2014 12:24, Glen Kent glen.k...@gmail.com wrote: http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen
Re: Heartbleed Bug Found in Cisco Routers, Juniper Gear
Either way, as I've said before, if you're exposing *any* management interfaces, be is ssh,netconf or https to the internet in general, you've got bigger issues than just heartbleed. Sure, i agree. VPN, on the other hand, is a totally different world of pain for this issue. What about VPNs? Glen /ruairi On 11 April 2014 12:24, Glen Kent glen.k...@gmail.com wrote: http://online.wsj.com/news/articles/SB10001424052702303873604579493963847851346 Glen
Chronic Abnormal Traceroutes Traversing Level 3
If there's anybody from Level 3 Transport available, I'd like to discuss some bizarre results when traversing through your network, namely in Dallas, TX over the past few months? I'm working this through your NOC as well, but figured I would cover all avenues as this issue is pretty chronic. Taken from your Looking Glass in Dallas to a destination of 195.110.36.136 1 vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 120 msec vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 120 msec vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 120 msec 2 ae-93-93.ebr3.Dallas1.Level3.net (4.69.151.170) 120 msec ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 120 msec ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 120 msec 3 ae-7-7.ebr4.Atlanta2.Level3.net (4.69.134.22) 36 msec 20 msec 20 msec 4 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 120 msec 116 msec 120 msec 5 ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 120 msec ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec 6 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 120 msec 120 msec ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 124 msec 7 ae-44-44.ebr2.Paris1.Level3.net (4.69.137.61) 120 msec ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 116 msec 116 msec 8 ae-62-62.csw1.Paris1.Level3.net (4.69.161.94) 124 msec ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 120 msec 120 msec 9 ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 120 msec ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 124 msec ae-71-71.ebr1.Paris1.Level3.net (4.69.161.81) 120 msec 10 ae-41-41.ebr2.London2.Level3.net (4.69.159.81) 120 msec 120 msec ae-43-43.ebr2.London2.Level3.net (4.69.159.89) 120 msec 11 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 116 msec 120 msec 120 msec 12 ae-26-26.car2.London2.Level3.net (4.69.200.98) 120 msec 120 msec 120 msec 13 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 120 msec 120 msec 120 msec 14 * * * 15 * * * 16 * * * I'm confused how the first and last hops are showing equal latency, while being half way around the world. I'm also confused why it's 120ms to the first hop from a route server local to that market. While I wouldn't rely on a traceroute as a true measurement of end to end latency, I'm having problems explaining to customers experiencing tangible issues when their traceroute looks like this: traceroute source 24.155.144.226 195.110.36.136 traceroute to 195.110.36.136 (195.110.36.136) from 24.155.144.226, 30 hops max, 40 byte packets 1 lag-8-868.ear1.Dallas1.Level3.net (4.30.74.53) 924.705 ms 545.117 ms 512.992 ms 2 4.69.146.5 (4.69.146.5) 124.812 ms 4.69.146.21 (4.69.146.21) 125.686 ms 4.69.146.9 (4.69.146.9) 124.018 ms MPLS Label=1965 CoS=0 TTL=1 S=1 3 ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 125.012 ms ae-83-83.ebr3.Dallas1.Level3.net (4.69.151.158) 141.585 ms ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 125.005 ms MPLS Label=1810 CoS=0 TTL=1 S=1 4 * * * 5 ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 126.085 ms 125.994 ms 127.148 ms MPLS Label=1692 CoS=0 TTL=1 S=1 6 ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.500 ms ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 125.369 ms ae-61-61.csw1.Washington1.Level3.net (4.69.134.130) 124.306 ms MPLS Label=1555 CoS=0 TTL=1 S=1 7 ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 131.126 ms 128.607 ms ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 123.955 ms MPLS Label=1636 CoS=0 TTL=1 S=1 8 ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 127.156 ms ae-41-41.ebr2.Paris1.Level3.net (4.69.137.49) 125.736 ms ae-43-43.ebr2.Paris1.Level3.net (4.69.137.57) 143.070 ms MPLS Label=1801 CoS=0 TTL=1 S=1 9 ae-82-82.csw3.Paris1.Level3.net (4.69.161.102) 122.998 ms 122.245 ms ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 124.499 ms MPLS Label=1564 CoS=0 TTL=1 S=1 10 ae-61-61.ebr1.Paris1.Level3.net (4.69.161.77) 129.705 ms ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 122.705 ms ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 126.454 ms MPLS Label=1322 CoS=0 TTL=1 S=1 11 ae-42-42.ebr2.London2.Level3.net (4.69.159.85) 126.019 ms 125.672 ms ae-44-44.ebr2.London2.Level3.net (4.69.159.93) 127.026 ms MPLS Label=1911 CoS=0 TTL=1 S=1 12 ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 122.058 ms 124.301 ms 123.397 ms MPLS Label=300112 CoS=0 TTL=1 S=1 13 ae-26-26.car2.London2.Level3.net (4.69.200.98) 124.003 ms 124.567 ms 130.346 ms 14 BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 125.316 ms 125.991 ms 124.968 ms 15 * * * This also doesn't seem to be circuit specific (Eliminating possible physical circuit errors, etc) as I have a secondary 10-Gig sourcing out of San Antonio, TX (Which ultimately terminates on your network in Dallas, same as the Austin
RE: Chronic Abnormal Traceroutes Traversing Level 3
Ah Ha! Thanks Nick and Trent! Well that explains the path being even at the MPLS cloud. JJ Stonebraker IP Network Engineering Grande Communications 512.878.5627 From: Trent Farrell [mailto:tfarr...@riotgames.com] Sent: Friday, April 11, 2014 11:19 AM To: Jack Stonebraker Cc: nanog@nanog.org Subject: Re: Chronic Abnormal Traceroutes Traversing Level 3 RTT gets calculated before the packet enters a MPLS network. On Fri, Apr 11, 2014 at 5:13 PM, Jack Stonebraker jack.stonebra...@mygrande.commailto:jack.stonebra...@mygrande.com wrote: If there's anybody from Level 3 Transport available, I'd like to discuss some bizarre results when traversing through your network, namely in Dallas, TX over the past few months? I'm working this through your NOC as well, but figured I would cover all avenues as this issue is pretty chronic. Taken from your Looking Glass in Dallas to a destination of 195.110.36.136 1 vlan70.csw2.Dallas1.Level3.nethttp://vlan70.csw2.Dallas1.Level3.net (4.69.145.126) 120 msec vlan60.csw1.Dallas1.Level3.nethttp://vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 120 msec vlan80.csw3.Dallas1.Level3.nethttp://vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 120 msec 2 ae-93-93.ebr3.Dallas1.Level3.nethttp://ae-93-93.ebr3.Dallas1.Level3.net (4.69.151.170) 120 msec ae-73-73.ebr3.Dallas1.Level3.nethttp://ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 120 msec ae-63-63.ebr3.Dallas1.Level3.nethttp://ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 120 msec 3 ae-7-7.ebr4.Atlanta2.Level3.nethttp://ae-7-7.ebr4.Atlanta2.Level3.net (4.69.134.22) 36 msec 20 msec 20 msec 4 ae-2-2.ebr1.Washington1.Level3.nethttp://ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 120 msec 116 msec 120 msec 5 ae-71-71.csw2.Washington1.Level3.nethttp://ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec ae-81-81.csw3.Washington1.Level3.nethttp://ae-81-81.csw3.Washington1.Level3.net (4.69.134.138) 120 msec ae-71-71.csw2.Washington1.Level3.nethttp://ae-71-71.csw2.Washington1.Level3.net (4.69.134.134) 120 msec 6 ae-92-92.ebr2.Washington1.Level3.nethttp://ae-92-92.ebr2.Washington1.Level3.net (4.69.134.157) 120 msec 120 msec ae-72-72.ebr2.Washington1.Level3.nethttp://ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) 124 msec 7 ae-44-44.ebr2.Paris1.Level3.nethttp://ae-44-44.ebr2.Paris1.Level3.net (4.69.137.61) 120 msec ae-42-42.ebr2.Paris1.Level3.nethttp://ae-42-42.ebr2.Paris1.Level3.net (4.69.137.53) 116 msec 116 msec 8 ae-62-62.csw1.Paris1.Level3.nethttp://ae-62-62.csw1.Paris1.Level3.net (4.69.161.94) 124 msec ae-72-72.csw2.Paris1.Level3.nethttp://ae-72-72.csw2.Paris1.Level3.net (4.69.161.98) 120 msec 120 msec 9 ae-81-81.ebr1.Paris1.Level3.nethttp://ae-81-81.ebr1.Paris1.Level3.net (4.69.161.85) 120 msec ae-91-91.ebr1.Paris1.Level3.nethttp://ae-91-91.ebr1.Paris1.Level3.net (4.69.161.89) 124 msec ae-71-71.ebr1.Paris1.Level3.nethttp://ae-71-71.ebr1.Paris1.Level3.net (4.69.161.81) 120 msec 10 ae-41-41.ebr2.London2.Level3.nethttp://ae-41-41.ebr2.London2.Level3.net (4.69.159.81) 120 msec 120 msec ae-43-43.ebr2.London2.Level3.nethttp://ae-43-43.ebr2.London2.Level3.net (4.69.159.89) 120 msec 11 ae-12-3202.edge4.London2.Level3.nethttp://ae-12-3202.edge4.London2.Level3.net (4.69.202.182) 116 msec 120 msec 120 msec 12 ae-26-26.car2.London2.Level3.nethttp://ae-26-26.car2.London2.Level3.net (4.69.200.98) 120 msec 120 msec 120 msec 13 BACKBONE-CO.car2.London2.Level3.nethttp://BACKBONE-CO.car2.London2.Level3.net (195.50.121.50) 120 msec 120 msec 120 msec 14 * * * 15 * * * 16 * * * I'm confused how the first and last hops are showing equal latency, while being half way around the world. I'm also confused why it's 120ms to the first hop from a route server local to that market. While I wouldn't rely on a traceroute as a true measurement of end to end latency, I'm having problems explaining to customers experiencing tangible issues when their traceroute looks like this: traceroute source 24.155.144.226 195.110.36.136 traceroute to 195.110.36.136 (195.110.36.136) from 24.155.144.226, 30 hops max, 40 byte packets 1 lag-8-868.ear1.Dallas1.Level3.nethttp://lag-8-868.ear1.Dallas1.Level3.net (4.30.74.53) 924.705 ms 545.117 ms 512.992 ms 2 4.69.146.5 (4.69.146.5) 124.812 ms 4.69.146.21 (4.69.146.21) 125.686 ms 4.69.146.9 (4.69.146.9) 124.018 ms MPLS Label=1965 CoS=0 TTL=1 S=1 3 ae-73-73.ebr3.Dallas1.Level3.nethttp://ae-73-73.ebr3.Dallas1.Level3.net (4.69.151.146) 125.012 ms ae-83-83.ebr3.Dallas1.Level3.nethttp://ae-83-83.ebr3.Dallas1.Level3.net (4.69.151.158) 141.585 ms ae-63-63.ebr3.Dallas1.Level3.nethttp://ae-63-63.ebr3.Dallas1.Level3.net (4.69.151.134) 125.005 ms MPLS Label=1810 CoS=0 TTL=1 S=1 4 * * * 5 ae-2-2.ebr1.Washington1.Level3.nethttp://ae-2-2.ebr1.Washington1.Level3.net (4.69.132.86) 126.085 ms 125.994 ms 127.148
Gmail contact please?
Is there a good contact at Gmail that can take care of a persistant issue for me? Thanks in advance, Dave Rand d...@kelkea.com or d...@bungi.com --
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 12 Apr, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 490753 Prefixes after maximum aggregation: 193016 Deaggregation factor: 2.54 Unique aggregates announced to Internet: 242489 Total ASes present in the Internet Routing Table: 46574 Prefixes per ASN: 10.54 Origin-only ASes present in the Internet Routing Table: 35707 Origin ASes announcing only one prefix: 16364 Transit ASes present in the Internet Routing Table:6067 Transit-only ASes present in the Internet Routing Table:173 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1855 Unregistered ASNs in the Routing Table: 471 Number of 32-bit ASNs allocated by the RIRs: 6366 Number of 32-bit ASNs visible in the Routing Table:4800 Prefixes from 32-bit ASNs in the Routing Table: 15763 Number of bogon 32-bit ASNs visible in the Routing Table:95 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:493 Number of addresses announced to Internet: 2667159300 Equivalent to 158 /8s, 249 /16s and 159 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 96.1 Total number of prefixes smaller than registry allocations: 171113 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 116260 Total APNIC prefixes after maximum aggregation: 34801 APNIC Deaggregation factor:3.34 Prefixes being announced from the APNIC address blocks: 119063 Unique aggregates announced from the APNIC address blocks:49824 APNIC Region origin ASes present in the Internet Routing Table:4911 APNIC Prefixes per ASN: 24.24 APNIC Region origin ASes announcing only one prefix: 1222 APNIC Region transit ASes present in the Internet Routing Table:859 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 25 Number of APNIC region 32-bit ASNs visible in the Routing Table:906 Number of APNIC addresses announced to Internet: 729825408 Equivalent to 43 /8s, 128 /16s and 64 /24s Percentage of available APNIC address space announced: 85.3 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:167314 Total ARIN prefixes after maximum aggregation:82965 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 168705 Unique aggregates announced from the ARIN address blocks: 78477 ARIN Region origin ASes present in the Internet Routing Table:16199 ARIN
DNSSEC?
So, DNSSEC is also compromised by this heartbleed bug, right? -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: DNSSEC?
On 04/11/2014 11:35 AM, Barry Shein wrote: So, DNSSEC is also compromised by this heartbleed bug, right? There is nothing in the DNSSEC protocol that requires the Heartbeat functionality. However whether a specific implementation of DNS software is vulnerable or not depends on how it's compiled. I would expect that most would not be. ISC for example just released a statement that BIND is not: https://lists.isc.org/pipermail/bind-users/2014-April/092944.html hth, Doug
Re: DNSSEC?
On Apr 11, 2014, at 11:35 AM, Barry Shein b...@world.std.com wrote: So, DNSSEC is also compromised by this heartbleed bug, right? Nope, apples and oranges. http://www.afilias.info/webfm_send/32 The only point of intersection I can think of is an indirect one, and unfortunately not much used yet: DANE certificates for TLS/SSL connections. -Bill signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Gmail contact please?
ICMP 0/0 On Apr 11, 2014 1:02 PM, Dave Rand d...@bungi.com wrote: Is there a good contact at Gmail that can take care of a persistant issue for me? Thanks in advance, Dave Rand d...@kelkea.com or d...@bungi.com --
Re: DNSSEC?
Once upon a time, Barry Shein b...@world.std.com said: So, DNSSEC is also compromised by this heartbleed bug, right? No, wrong. The OpenSSL bug involves an extension to the TLS protocol called heartbeat (basically like a TCP or PPP keepalive). DNSSEC does not use TLS (or any other kind of transport encryption). -- Chris Adams c...@cmadams.net
Fwd: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
I'm not forwarding this to get into politics. I'm forwarding it because of the impact on operational security. Given the recent I hunt sysadmins leak, I think it's not unreasonable to suggest that everyone on this list has probably been targeted because of their privileged access to networks/servers/services/etc. ---rsk - Forwarded message from Richard Forno rfo...@infowarrior.org - Date: Fri, 11 Apr 2014 15:05:03 -0400 From: Richard Forno rfo...@infowarrior.org To: Infowarrior List infowarr...@attrition.org Subject: [Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years NSA Said to Have Used Heartbleed Bug, Exposing Consumers By Michael Riley Apr 11, 2014 2:58 PM ET http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA's decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government's top computer experts. Heartbleed appears to be one of the biggest glitches in the Internet's history, a flaw in the basic security of as many as two-thirds of the world's websites. Its discovery and the creation of a fix by researchers five days ago prompted consumers to change their passwords, the Canadian government to suspend electronic tax filing and computer companies including Cisco Systems Inc. to Juniper Networks Inc. to provide patches for their systems. Putting the Heartbleed bug in its arsenal, the NSA was able to obtain passwords and other basic data that are the building blocks of the sophisticated hacking operations at the core of its mission, but at a cost. Millions of ordinary users were left vulnerable to attack from other nations' intelligence arms and criminal hackers. Controversial Practice It flies in the face of the agency's comments that defense comes first, said Jason Healey, director of the cyber statecraft initiative at the Atlantic Council and a former Air Force cyber officer. They are going to be completely shredded by the computer security community for this. [snip]
Re: DNSSEC?
On April 11, 2014 at 11:44 do...@dougbarton.us (Doug Barton) wrote: On 04/11/2014 11:35 AM, Barry Shein wrote: So, DNSSEC is also compromised by this heartbleed bug, right? There is nothing in the DNSSEC protocol that requires the Heartbeat functionality. However whether a specific implementation of DNS software is vulnerable or not depends on how it's compiled. I would expect that most would not be. ISC for example just released a statement that BIND is not: https://lists.isc.org/pipermail/bind-users/2014-April/092944.html Cool, good news. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: DNSSEC?
On 11 Apr 2014, at 21:25, Chris Adams c...@cmadams.net wrote: DNSSEC does not use TLS (or any other kind of transport encryption). The administrative interfaces controlling the implementation might still do. Grüße, Carsten
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA's decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government's top computer experts. I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. These two unnamed sources are liars. Bet on it. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
* b...@herrin.us (William Herrin) [Fri 11 Apr 2014, 22:04 CEST]: I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. Have you been paying attention at all. Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than it seems unlikely to me personally. -- Niels.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
I wrote: I'm not saying this has been happening ... but here's the same news from a much more credible source: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html Still anonymously sourced but at least via people whose ability to vet sources you can usually trust. -- Niels.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
* Niels Bakker (niels=na...@bakker.net) wrote: but here's the same news from a much more credible source: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html Still anonymously sourced but at least via people whose ability to vet sources you can usually trust. hum. That was included in the original post... Stephen signature.asc Description: Digital signature
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
Once upon a time, Niels Bakker niels=na...@bakker.net said: but here's the same news from a much more credible source: Actually, that's the same news _from the same source_ as originally posted. That article also has other wonderful bits like: The Heartbleed flaw, introduced in early 2012 in a minor adjustment to the OpenSSL protocol, highlights one of the failings of open source software development. While many Internet companies rely on the free code, its integrity depends on a small number of underfunded researchers who devote their energies to the projects. This is fairly typical big-business denigration of Open Source, ignoring the fact that (a) closed source software doesn't get reviewed for things like this, and (b) code like this isn't just written by underfunded researchers. Red Hat (a billion-dollar company) got their package of OpenSSL through FIPS certification. Even the opening of the article: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, The flaw has only existed for two years and a couple of weeks (and how many websites deployed a brand-new OpenSSL the day it came out?). So unless the patch was authored by the NSA (which the patch author claims is not the case), they'd have to have known about it before it existed. I don't even fully buy the two-thirds of the world's websites. I'm not sure that 2/3 of the websites I visit even use SSL. Also, many versions of enterprise OSes like Red Hat Enterprise Linux weren't affected (RHEL 5 was not affected, and RHEL 6 was only affected starting with 6.5 from last November). There are a lot of web servers that aren't updated that often (or stay with more stable release trains). -- Chris Adams c...@cmadams.net
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 11, 2014 at 04:03:36PM -0400, William Herrin wrote: If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. unusually gutsy compared to what, EXACTLY? Sources: NSA sucks in data from 50 companies http://theweek.com/article/index/245311/sources-nsa-sucks-in-data-from-50-companies Report: NSA Circumvented Encryption http://www.bankinfosecurity.com/report-nsa-circumvented-encryption-a-6045 [ That one is interesting, by the way. It's from September 6, 2013, and quotes reporting by the New York Times and Pro Publica the previous day. Here's an excerpt: Bruce Schneier, a widely followed cryptography expert, author and blogger, characterizes the revelation as explosive. Basically, the NSA is able to decrypt most of the Internet, he writes in his blog. They're doing it primarily by cheating, not by mathematics. ... Remember this: The math is good, but math has no agency. Code has agency, and the code has been subverted. According to the news report, some of NSA's most exhaustive efforts have concentrated on encryption widely used in the United States, including Secure Sockets Layer, virtual private networks and the protection used on fourth generation smart phones. Interesting that it mentions SSL, isn't it? ] NSA's pipe dream: Weakening crypto will only help the good guys http://arstechnica.com/security/2013/09/nsas-pipe-dream-weakening-crypto-will-only-help-the-good-guys/ Exclusive: NSA infiltrated RSA security more deeply than thought http://www.reuters.com/article/2014/03/31/us-usa-security-nsa-rsa-idUSBREA2U0TY20140331?feedType=RSSfeedName=topNewsutm_source=dlvr.itutm_medium=twitterdlvrit=992637 NSA Aiming To Infect Millions Of Computers Worldwide With Its Malware; Targets Telco/ISP Systems Administrators http://www.techdirt.com/articles/20140312/07334826545/nsa-aiming-to-infect-millions-computers-worldwide-with-its-malware-targets-telcoisp-systems-administrators.shtml NSA hacker in residence dishes on how to hunt system admins http://arstechnica.com/security/2014/03/nsa-hacker-in-residence-dishes-on-how-to-hunt-system-admins/ Let me note in passing that the NSA is not the only intelligence agency on this planet that has demonstrated both willingness and ability to create and/or exploit large scale security breaches in order to acquire information. Surely nobody thinks that folks in Moscow and London and Berlin and Bejing were just sitting on their hands. ---rsk
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker niels=na...@bakker.net wrote: Please go read up on some recent and less recent history before making judgments on what would be unusually gutsy for that group of people. I'm not saying this has been happening but you will have to come up with a better defense than it seems unlikely to me personally. Let me know when someone finds the second shooter on the grassy knoll. As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word sensitive does not do justice to the attention lavished on THEIR servers' security. In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. -Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: DNSSEC?
On Fri, Apr 11, 2014 at 09:37:38PM +0200, Carsten Bormann wrote: On 11 Apr 2014, at 21:25, Chris Adams c...@cmadams.net wrote: DNSSEC does not use TLS (or any other kind of transport encryption). The administrative interfaces controlling the implementation might still do. That's not DNSSEC that's broken, then. - Matt -- Mr... Baggins. It seems you have been leading... two lives. In one... you are an ordinary hobbit... you organize your uncle's diary... give generous gifts to children. In the other... you are the Ring Bearer... charged to carry the One Ring to Mount Doom. One life has... a future, Mr... Baggins, and the other...
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 11, 2014 at 04:03:36PM -0400, William Herrin wrote: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA's decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government's top computer experts. I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. You're assuming that the NSA is a single monolithic entity. IIRC, the offense team and the defense team don't really talk much, and they *certainly* have very different motivations. It wouldn't surprise me at all if the offense got hold of a juicy bug, and since they're paid to capture data, and knowing that they wouldn't get in trouble if the defense lost data, their motivations to keep their little bug to themselves are entirely understandable. The interesting thing to me is that the article claims the NSA have been using this for over two years, but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA put it in there (still a bridge too far for me to believe without further evidence, although I can certainly understand why people could believe it) and hence were using it from day 1; * The NSA found it *amazingly* quickly (they're very good at what they do, but I don't believe them have superhuman talents); or * The article has got at least one fact wrong, in which case it's entirely plausible they've got other things wrong, too. - Matt -- That's why I love VoIP. You don't get people phoning up to complain that the network is down. -- Peter Corlett, in the Monastery
The Cidr Report
This report has been generated at Fri Apr 11 21:13:53 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
04-04-14494011 279041
05-04-14494614 278808
06-04-14494695 279258
07-04-14494768 279209
08-04-14494723 281417
09-04-14497900 281706
10-04-14498626 281966
11-04-14498748 282193
AS Summary
46790 Number of ASes in routing system
19080 Number of ASes announcing only one prefix
3594 Largest number of prefixes announced by an AS
AS28573: NET Serviços de Comunicação S.A.,BR
119829504 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 11Apr14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 498391 282236 21615543.4% All ASes
AS28573 3594 350 324490.3% NET Serviços de Comunicação
S.A.,BR
AS6389 2996 56 294098.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2781 237 254491.5% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS4766 2919 907 201268.9% KIXS-AS-KR Korea Telecom,KR
AS18881 1922 35 188798.2% Global Village Telecom,BR
AS1785 2192 479 171378.1% AS-PAETEC-NET - PaeTec
Communications, Inc.,US
AS18566 2047 565 148272.4% MEGAPATH5-US - MegaPath
Corporation,US
AS10620 2820 1339 148152.5% Telmex Colombia S.A.,CO
AS4323 2940 1520 142048.3% TWTC - tw telecom holdings,
inc.,US
AS36998 1637 248 138984.9% SDN-MOBITEL,SD
AS7303 1751 452 129974.2% Telecom Argentina S.A.,AR
AS4755 1843 608 123567.0% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS7545 2231 1085 114651.4% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS7552 1224 119 110590.3% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1309 241 106881.6% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS6983 1228 217 101182.3% ITCDELTA - Earthlink, Inc.,US
AS22773 2414 1467 94739.2% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS4808 1366 426 94068.8% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network,CN
AS9829 1622 719 90355.7% BSNL-NIB National Internet
Backbone,IN
AS24560 1123 297 82673.6% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services,IN
AS4788 1023 252 77175.4% TMNET-AS-AP TM Net, Internet
Service Provider,MY
AS18101 943 183 76080.6% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI,IN
AS8151 1407 661 74653.0% Uninet S.A. de C.V.,MX
AS7738 914 182 73280.1% Telemar Norte Leste S.A.,BR
AS701 1480 751 72949.3% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business,US
AS855764 57 70792.5% CANET-ASN-4 - Bell Aliant
Regional Communications,
Inc.,CA
AS4780 1036 368 66864.5% SEEDNET Digital United Inc.,TW
AS6147 781 113 66885.5% Telefonica del Peru S.A.A.,PE
AS26615
BGP Update Report
BGP Update Report Interval: 03-Apr-14 -to- 10-Apr-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS36998 73697 3.1% 46.4 -- SDN-MOBITEL,SD 2 - AS982972918 3.0% 78.7 -- BSNL-NIB National Internet Backbone,IN 3 - AS27738 57295 2.4% 99.5 -- Ecuadortelecom S.A.,EC 4 - AS29571 41104 1.7% 384.1 -- CITelecom-AS,CI 5 - AS13188 28842 1.2% 27.4 -- BANKINFORM-AS TOV Bank-Inform,UA 6 - AS840227938 1.2% 32.9 -- CORBINA-AS OJSC Vimpelcom,RU 7 - AS56115 24373 1.0% 369.3 -- NGGL-BD Road 27 House 13 Block C2,BD 8 - AS381623167 1.0% 65.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 9 - AS13118 22914 1.0% 11457.0 -- ASN-YARTELECOM OJSC Rostelecom,RU 10 - AS45899 20767 0.9% 66.1 -- VNPT-AS-VN VNPT Corp,VN 11 - AS14259 20688 0.9% 157.9 -- Gtd Internet S.A.,CL 12 - AS165920579 0.9% 78.2 -- ERX-TANET-ASN1 Tiawan Academic Network (TANet) Information Center,TW 13 - AS41691 20470 0.9%1137.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 14 - AS25184 20123 0.8% 157.2 -- AFRANET AFRANET Co. Tehran, Iran,IR 15 - AS23893 15713 0.7% 402.9 -- BPL-BD House No:03, Road no: 23/A,BD 16 - AS178515604 0.7% 35.3 -- AS-PAETEC-NET - PaeTec Communications, Inc.,US 17 - AS755215254 0.6% 47.4 -- VIETEL-AS-AP Viettel Corporation,VN 18 - AS17557 14714 0.6% 216.4 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK 19 - AS48159 14614 0.6% 74.6 -- TIC-AS Telecommunication Infrastructure Company,IR 20 - AS702914267 0.6% 81.1 -- WINDSTREAM - Windstream Communications Inc,US TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS13118 22914 1.0% 11457.0 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - AS181358939 0.4%8939.0 -- BTV BTV Cable television,JP 3 - AS6459 7711 0.3%7711.0 -- TRANSBEAM - I-2000, Inc.,US 4 - AS20450 13280 0.6%6640.0 -- THL16-ASN - Trojan Hosting, LLC.,US 5 - AS544658401 0.3%2800.3 -- QPM-AS-1 - QuickPlay Media Inc.,US 6 - AS588227262 0.3%2420.7 -- IDNIC-UNESA-AS-ID Universitas Negeri Surabaya,ID 7 - AS662910536 0.4%2107.2 -- NOAA-AS - NOAA,US 8 - AS31490 0.1%1987.0 -- MIT-GATEWAYS - Massachusetts Institute of Technology,US 9 - AS41691 20470 0.9%1137.2 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 10 - AS603451064 0.0%1064.0 -- NBITI-AS Nahjol Balagheh International Research Institution,IR 11 - AS45636 972 0.0% 972.0 -- D2H-BBCL-IN Plot No. 1D, Udyog Vihar Industrial Estate,IN 12 - AS389092898 0.1% 966.0 -- MURAMATSU-AS-AP Muramatsu Group Inc. Transit AS,PH 13 - AS23466 828 0.0% 828.0 -- -Reserved AS-,ZZ 14 - AS232951623 0.1% 811.5 -- EA-01 - Extend America,US 15 - AS22294 0.1%2024.0 -- UDEL-DCN - University of Delaware,US 16 - AS21973 648 0.0% 648.0 -- XPONET - Xponet,US 17 - AS33643 640 0.0% 640.0 -- JELLYBELLY - Jelly Belly Candy Company,US 18 - AS387303196 0.1% 639.2 -- VIETINBANK-AS-VN Vietnam Bank for Industry and Trade,VN 19 - AS570134455 0.2% 636.4 -- EURASIA-STAR-AS Eurasia Star Ltd.,KZ 20 - AS45900 632 0.0% 632.0 -- SBV-AS-VN The State Bank of Viet Nam,VN TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/20 22906 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom,RU 2 - 89.221.206.0/24 20390 0.8% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC,RU 3 - 121.52.144.0/24 14696 0.6% AS17557 -- PKTELECOM-AS-PK Pakistan Telecommunication Company Limited,PK AS45773 -- HECPERN-AS-PK PERN AS Content Servie Provider, Islamabad, Pakistan,PK 4 - 187.188.205.0/24 10667 0.4% AS17072 -- Iusacell PCS de Mexico, S.A. de C.V.,MX 5 - 192.58.232.0/24 10531 0.4% AS6629 -- NOAA-AS - NOAA,US 6 - 78.109.192.0/209640 0.4% AS25184 -- AFRANET AFRANET Co. Tehran, Iran,IR 7 - 42.83.48.0/20 8939 0.3% AS18135 -- BTV BTV Cable television,JP 8 - 206.152.15.0/248395 0.3% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.,US 9 - 205.247.12.0/247711 0.3% AS6459 -- TRANSBEAM - I-2000, Inc.,US 10 - 65.90.49.0/24 7069 0.3% AS3356 -- LEVEL3 - Level 3 Communications, Inc.,US 11 - 66.210.60.0/24 6685 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 12 - 74.231.237.0/246595 0.3% AS20450 -- THL16-ASN - Trojan Hosting, LLC.,US 13 - 199.187.118.0/24 4365
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On 4/11/2014 4:03 PM, William Herrin wrote: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA's decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government's top computer experts. I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. These two unnamed sources are liars. Bet on it. Regards, Bill Herrin I would imagine that federal contractors have to adhere to FIPS 140-2 standards (or some similar requirement) for sensitive environments, and none of the affected OpenSSL versions were certified to any FIPS standard... the last version that WAS certified (0.9.8j) is only rated to Level 1, which, being the lowest possible rating, I suspect is not permitted for use by NSA contractors -- they're probably required to use level 3 or 4 for everything.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 11, 2014 at 5:56 PM, Matt Palmer mpal...@hezmatt.org wrote: You're assuming that the NSA is a single monolithic entity. IIRC, the offense team and the defense team don't really talk much, and they *certainly* have very different motivations. It wouldn't surprise me at all if the offense got hold of a juicy bug, and since they're paid to capture data, and knowing that they wouldn't get in trouble if the defense lost data, their motivations to keep their little bug to themselves are entirely understandable. Hi Matt, I assume only individual motivations, like CYA. Folks at the bottom don't make bold decisions. A potentially career-making or career-ending decision like this would have been kicked up the chain until it reached someone who could, after consulting several other folks to cover his own posterior, authorize the risk. This and the high odds of a leak are how I know the NSA hasn't cracked the prime factoring problem either. And anyone surprised by Snowden's revelations either didn't read about or didn't understand Mark Klein's 2006 ATT documents. There are things that folks at the NSA could plausibly be doing. Intentionally sitting on a massive security hole in their own systems for two years isn't one of them. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Severe latency at both San Jose and Los Angeles Level3/ATT peering
Hi Nanog, I have a ticket open with Level 3, with whom I have 1gig pipes in Oakland, CA and Las Vegas, NV. One of our users noticed very slow file transfer/media delivery from the Bay Area to L.A., and on investigating it appears as though the peering point between Level3 and ATT in SF was saturated and had 300ms avg. latency. 90 minutes later after receiving no call from Level3, I escalated to a P1 ticket, as the latency is now 1000ms and we're seeing 20% packet loss. I decided to statically route to the destination via our DR cluster in Vegas, and interestingly I found the same situation where ATT and Level3 peer in Tustin. mtr traceroutes, for those curious: Via Oakland: My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:08 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.3 0.2 0.1 0.3 0.1 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.4 0.5 0.0 3. verge-vlan66.pixar.com 0.0% 0.6 0.7 0.6 0.9 0.1 4. ge-6-24.car1.Oakland1.Level3.net 0.0% 0.7 105.5 0.7 307.3 110.9 5. ae-5-5.ebr2.SanJose1.Level3.net 0.0% 1.7 1.7 1.6 2.8 0.4 6. ae-92-92.csw4.SanJose1.Level3.net0.0% 1.6 1.7 1.6 3.0 0.4 7. ae-4-90.edge2.SanJose1.Level3.net0.0% 1.6 4.6 1.6 37.1 10.2 8. 192.205.32.209 41.7% 1042. 1048. 1038. 1059. 9.1 9. cr1.sffca.ip.att.net25.0% 1052. 1059. 1046. 1072. 10.0 10. cr1.la2ca.ip.att.net27.3% 1043. 1060. 1043. 1071. 10.7 11. cr83.la2ca.ip.att.net 16.7% 1058. 1060. 1045. 1073. 8.8 12. gar7.la2ca.ip.att.net 16.7% 1059. 1061. 1044. 1087. 13.3 13. 12.249.143.98 33.3% 1059. 1057. 1048. 1071. 7.8 14. ??? My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:43 2014 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.2 0.1 0.1 0.2 0.0 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.3 0.6 0.1 3. cat-vegas-01-vlan66.pixar.com0.0% 22.0 21.8 21.7 22.3 0.2 4. 205.129.21.101 0.0% 19.4 19.5 19.3 19.9 0.2 5. ae-2-5.bar1.LasVegas1.Level3.net 0.0% 19.3 21.8 19.3 40.7 5.9 6. ae-4-4.ebr1.LosAngeles1.Level3.net 0.0% 22.0 22.4 21.9 26.8 1.3 7. ae-6-6.ebr1.Tustin1.Level3.net 0.0% 20.0 20.2 19.9 21.8 0.5 8. ae-107-3507.bar2.Tustin1.Level3.net 0.0% 22.0 22.0 21.9 22.1 0.0 9. 192.205.37.145 30.8% 1052. 1063. 1048. 1072. 8.1 10. cr1.la2ca.ip.att.net35.7% 1050. 1060. 1050. 1070. 7.3 11. cr83.la2ca.ip.att.net 28.6% 1049. 1064. 1049. 1072. 7.8 12. gar7.la2ca.ip.att.net 21.4% 1048. 1061. 1048. 1072. 6.7 13. 12.249.143.98 28.6% 1050. 1061. 1050. 1072. 7.9 14. ??? Just wanted to share in case anyone else is running into similar issues. I know, I should be on the outages list. I will add myself now. :) Regards, Dave Sotnick
Re: DNSSEC?
On 4/11/2014 5:47 PM, Matt Palmer wrote: That's not DNSSEC that's broken, then. - Matt You're correct about that, but everything depends on your level of paranoia. The bug has a potential to show 64k of memory that may or may not be a part of the TLS/SSL connection*. In that 64k their may be ssh keys, dnssec keys, pictures of cats, or anything else that needs to be safely protected. If something is very important to keep secure and it was on a box that has a TLS/SSL connection then you should regenerate keys for it, but largely this effort would be just in case and not because it's compromised. * technically it is part of the connection, it's just malloc() and not zeroed so whatever data was in it before was not cleared. If you can be sure all your cat picture applications zero memory on exit and none of them exited uncleanly then this isn't a problem. At high levels of paranoia this isn't really something that you can be sure of though. I'm not even sure if it's done in most crypto apps aside from gpg. OpenSSL is double-faulted here for both not checking the length and not zeroing the memory on malloc**. ** probably making this all up since I haven't done a real look at the library, I'm just going by what I've read on the internet. I expect we may see more bugs revealed in openssl soon. It's getting lots of scrutiny from this so I expect the code is being audit by everyone and that's good.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
And their Level 3 to 4 accomplished what exactly?? They were owned the same way the own others, from the inside. On 4/11/14, 4:27 PM, Peter Kristolaitis alte...@alter3d.ca wrote: On 4/11/2014 4:03 PM, William Herrin wrote: The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said. The NSA's decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government's top computer experts. I call B.S. Do you have any idea how many thousands of impacted NSA servers run by contractors hung out on the Internet with sensitive NSA data? If you told me they used it against the targets of the day while putting out the word to patch I could buy it, but intentionally leaving a certain bodily extension hanging in the breeze in the hopes of gaining more valuable data than they lose would have been an unusually gutsy move. These two unnamed sources are liars. Bet on it. Regards, Bill Herrin I would imagine that federal contractors have to adhere to FIPS 140-2 standards (or some similar requirement) for sensitive environments, and none of the affected OpenSSL versions were certified to any FIPS standard... the last version that WAS certified (0.9.8j) is only rated to Level 1, which, being the lowest possible rating, I suspect is not permitted for use by NSA contractors -- they're probably required to use level 3 or 4 for everything.
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
--- mpal...@hezmatt.org wrote: From: Matt Palmer mpal...@hezmatt.org The interesting thing to me is that the article claims the NSA have been using this for over two years, but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA put it in there (still a bridge too far for me to believe without further evidence, although I can certainly understand why people could believe it) and hence were using it from day 1; --- Why is a mole in the IETF subverting things hard to believe? ;-) scott
Re: DNSSEC?
In message 534874d8.3050...@direcpath.com, Robert Drake writes: On 4/11/2014 5:47 PM, Matt Palmer wrote: That's not DNSSEC that's broken, then. - Matt You're correct about that, but everything depends on your level of paranoia. The bug has a potential to show 64k of memory that may or may not be a part of the TLS/SSL connection*. In that 64k their may be ssh keys, dnssec keys, pictures of cats, or anything else that needs to be safely protected. If something is very important to keep secure and it was on a box that has a TLS/SSL connection then you should regenerate keys for it, but largely this effort would be just in case and not because it's compromised. That bug has the potential to show what is in them memory of the process it is connecting to. Note I said process not machine. Now unless you are using SSL to take to a process that is signing DNSSEC keys there is no exposure of the private keys. Named doesn't use ssl. There are however nameservers that do use ssl to work around broken middle boxes. If they are also signing zones then there is potential to expose private keys. That said it also depends on how the process manages the memory it frees. Named for example overwrites freed memory with 0xde. It also initialises allocated memory with 0xbe. Doing so help detect use after free and use of uninitialised structure elements. We want to catch these sorts of bugs before they get to the internal review stage. * technically it is part of the connection, it's just malloc() and not zeroed so whatever data was in it before was not cleared. If you can be sure all your cat picture applications zero memory on exit and none of them exited uncleanly then this isn't a problem. At high levels of paranoia this isn't really something that you can be sure of though. I'm not even sure if it's done in most crypto apps aside from gpg. OpenSSL is double-faulted here for both not checking the length and not zeroing the memory on malloc**. ** probably making this all up since I haven't done a real look at the library, I'm just going by what I've read on the internet. I expect we may see more bugs revealed in openssl soon. It's getting lots of scrutiny from this so I expect the code is being audit by everyone and that's good. I also expect to see more bugs revealed in MacOS, Windows, FreeBSD and any other program written by humans or written by programs written by humans. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: The interesting thing to me is that the article claims the NSA have been using this for over two years, but 1.0.1 (the first vulnerable version) was only released on 14 Mar 2012. That means that either: * The NSA found it *amazingly* quickly (they're very good at what they do, but I don't believe them have superhuman talents); or You seriously think the NSA *isn't* watching the commits to security-relevant open source? Remember - it was a bonehead bug, it's *not* unreasonable for somebody who was auditing the code to spot it. Heck, there's a good chance that automated tools could have spotted it. pgpumtq4kr1RX.pgp Description: PGP signature
Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
On Fri, Apr 11, 2014 at 6:27 PM, Peter Kristolaitis alte...@alter3d.ca wrote: I would imagine that federal contractors have to adhere to FIPS 140-2 standards (or some similar requirement) for sensitive environments, and none of the affected OpenSSL versions were certified to any FIPS standard... the last version that WAS certified (0.9.8j) is only rated to Level 1, which, being the lowest possible rating, I suspect is not permitted for use by NSA contractors -- they're probably required to use level 3 or 4 for everything. Some of the time, sure. And some of the time they buy Red Hat Linux off the shelf like everybody else. They have budgets too. They can't do everything at the highest protection level. Or did you think they were above and immune to the ordinary business realities of the 21st century? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Fwd: [IP] Summary of what I know so far about the Linksys botnet and/or worm
Any comments? -- Forwarded message -- From: Dave Farber d...@farber.net Date: Fri, Apr 11, 2014 at 8:13 PM Subject: [IP] Summary of what I know so far about the Linksys botnet and/or worm To: ip i...@listbox.com -- Forwarded message -- From: *Brett Glass* br...@lariat.net Date: Wednesday, February 12, 2014 Subject: Summary of what I know so far about the Linksys botnet and/or worm To: Eugene H. Spafford s...@acm.org, d...@farber.net d...@farber.net Cc: secur...@linksys.com Gene, Dave: Here is what I know so far about the Linksys router exploit that I've been observing in the wild today. * The exploit has affected Linksys E1000 and E1200 routers that have public IP addresses on our network. Those which we've shielded behind carrier-grade NAT (the majority) have not been compromised. * The routers are rapidly scanning blocks of IP addresses for Web servers on ports 80 and 8080. This choice of ports seems to indicate that they are looking for other routers of their ilk to infect. It's unclear whether, once they find a vulnerable router, they infect it themselves or report its IP address back to a botmaster for later infection. I suspect the latter, though, because infection would require flashing the router with a modified firmware image that would be model-specific and there is not room in a router for multiple images. It's also likely that a central server is coordinating the scans. * All of the E1000s that have been affected have the last version of firmware that was made for this now-discontinued model. The affected E1200s have firmware version 1.0.03 (the last one published for hardware version 1) or 2.0.04 (not the latest for hardware version 2, but close; there's now a 2.0.06. I do not know if 2.0.06 stops the exploit because we have no E1200s running it with public IPs). We have not seen any E900s infected, even though the E900 and the E1200 use the same hardware. * None of the infected routers had default or easily guessable passwords, suggesting that the backdoor or security hole through which the exploit was performed did not require guessing a password. * Re-flashing routers and resetting them to factory defaults SEEMS to clear the malware, but of course one cannot be 100% sure that it does not protect itself from re-flashing. * These routers use Broadcom chipsets and Wind River's RTOS operating system, and it wasn't swapped for a Linux-based one, so the creators of the malware must be skilled in development for this OS -- or at least sufficiently skilled to modify the firmware. At this point, it appears that those who implemented this exploit is still building an army and has not used it for anything yet. However, there are so many millions of these routers in the field, with so many private networks behind them, that there's no telling just how much havoc they could wreak if they were set to invasion of privacy, DoS attacks, etc. I haven't been able to get in touch with anyone at Linksys to talk about this. Their support techs are all in remote call centers in far-flung corners of the world, and I have not been able to get them to escalate. --Brett Glass Archives https://www.listbox.com/member/archive/247/=now https://www.listbox.com/member/archive/rss/247/125534-14f1b966 | Modifyhttps://www.listbox.com/member/?member_id=125534id_secret=125534-f26397ecYour Subscription | Unsubscribe Nowhttps://www.listbox.com/unsubscribe/?member_id=125534id_secret=125534-8937d9eepost_id=20140411201339:49F005E2-C1D7-11E3-AB53-859A868D5D56 http://www.listbox.com -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Severe latency at both San Jose and Los Angeles Level3/ATT peering
This should provide some background: http://apps.fcc.gov/ecfs/document/view?id=7022026095 Drive Slow, Paul On Fri, Apr 11, 2014 at 6:50 PM, David Sotnick sotnickd-na...@ddv.com wrote: Hi Nanog, I have a ticket open with Level 3, with whom I have 1gig pipes in Oakland, CA and Las Vegas, NV. One of our users noticed very slow file transfer/media delivery from the Bay Area to L.A., and on investigating it appears as though the peering point between Level3 and ATT in SF was saturated and had 300ms avg. latency. 90 minutes later after receiving no call from Level3, I escalated to a P1 ticket, as the latency is now 1000ms and we're seeing 20% packet loss. I decided to statically route to the destination via our DR cluster in Vegas, and interestingly I found the same situation where ATT and Level3 peer in Tustin. mtr traceroutes, for those curious: Via Oakland: My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:08 2014 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.3 0.2 0.1 0.3 0.1 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.4 0.5 0.0 3. verge-vlan66.pixar.com 0.0% 0.6 0.7 0.6 0.9 0.1 4. ge-6-24.car1.Oakland1.Level3.net 0.0% 0.7 105.5 0.7 307.3 110.9 5. ae-5-5.ebr2.SanJose1.Level3.net 0.0% 1.7 1.7 1.6 2.8 0.4 6. ae-92-92.csw4.SanJose1.Level3.net0.0% 1.6 1.7 1.6 3.0 0.4 7. ae-4-90.edge2.SanJose1.Level3.net0.0% 1.6 4.6 1.6 37.1 10.2 8. 192.205.32.209 41.7% 1042. 1048. 1038. 1059. 9.1 9. cr1.sffca.ip.att.net25.0% 1052. 1059. 1046. 1072. 10.0 10. cr1.la2ca.ip.att.net27.3% 1043. 1060. 1043. 1071. 10.7 11. cr83.la2ca.ip.att.net 16.7% 1058. 1060. 1045. 1073. 8.8 12. gar7.la2ca.ip.att.net 16.7% 1059. 1061. 1044. 1087. 13.3 13. 12.249.143.98 33.3% 1059. 1057. 1048. 1071. 7.8 14. ??? My traceroute [v0.71] hivemind (0.0.0.0) Fri Apr 11 15:36:43 2014 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Last Avg Best Wrst StDev 1. 138.72.xxx.xxx 0.0% 0.2 0.1 0.1 0.2 0.0 2. pan5060-ae1-401.routerland.pixar.com 0.0% 0.4 0.4 0.3 0.6 0.1 3. cat-vegas-01-vlan66.pixar.com0.0% 22.0 21.8 21.7 22.3 0.2 4. 205.129.21.101 0.0% 19.4 19.5 19.3 19.9 0.2 5. ae-2-5.bar1.LasVegas1.Level3.net 0.0% 19.3 21.8 19.3 40.7 5.9 6. ae-4-4.ebr1.LosAngeles1.Level3.net 0.0% 22.0 22.4 21.9 26.8 1.3 7. ae-6-6.ebr1.Tustin1.Level3.net 0.0% 20.0 20.2 19.9 21.8 0.5 8. ae-107-3507.bar2.Tustin1.Level3.net 0.0% 22.0 22.0 21.9 22.1 0.0 9. 192.205.37.145 30.8% 1052. 1063. 1048. 1072. 8.1 10. cr1.la2ca.ip.att.net35.7% 1050. 1060. 1050. 1070. 7.3 11. cr83.la2ca.ip.att.net 28.6% 1049. 1064. 1049. 1072. 7.8 12. gar7.la2ca.ip.att.net 21.4% 1048. 1061. 1048. 1072. 6.7 13. 12.249.143.98 28.6% 1050. 1061. 1050. 1072. 7.9 14. ??? Just wanted to share in case anyone else is running into similar issues. I know, I should be on the outages list. I will add myself now. :) Regards, Dave Sotnick
RE: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
I'm not sure if anyone of you has access to those automated tools, but I'd be interested in learning if any of them do catch the bug. Frank -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Friday, April 11, 2014 7:50 PM To: Matt Palmer Cc: nanog@nanog.org Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] On Sat, 12 Apr 2014 07:56:01 +1000, Matt Palmer said: snip Heck, there's a good chance that automated tools could have spotted it.
Re: DNSSEC?
On Fri, Apr 11, 2014 at 6:03 PM, Robert Drake rdr...@direcpath.com wrote: The bug has a potential to show 64k of memory that may or may not be a part of the TLS/SSL connection*. It has the potential to show various pieces of memory 64K at a time that may be related to ANY of the data the OpenSSL library works with associated with the same process. In that 64k their may be ssh keys, dnssec keys, pictures of cats, or anything else that needs to be safely protected. If Unlikely. For this vuln to be an issue: You need to have a vulnerable application or service that uses the SSL or TLS protocol and is sending or receiving those SSH or DNSSEC keys. something is very important to keep secure and it was on a box that has a TLS/SSL connection then you should regenerate keys for it, but largely this In most cases, this would be an unwarranted excessive response. For instance a SSL vuln affecting apache is not ordinarily an information leak risk equivalent to a full on root compromise. Most simply need to address secret credentials that may have been used by, transmitted, or received through a vulnerable client, server program, or app running on a vulnerable runtime framework (e.g. PHP script running on Apache with OpenSSL based mod_ssl, not Apache if using mod_nss/LibNSS instead of OpenSSL's libssl). BIND and SSH were unaffected, so... efficient and effective mitigation would not entail routinely treating these applications as if they were affected, in the absence of other issues. * technically it is part of the connection, it's just malloc() and not zeroed so whatever data was in it before was not cleared. If you can be sure all your cat picture applications zero memory on exit and none of them exited uncleanly then this isn't a problem. At high levels of paranoia this The memory leaked is not arbitrary memory spanning the entire box --- it is going to be memory belonging to the heap space of the same process instance, and almost certainly memory buffers which the OpenSSL library previously allocated for purposes such as sending/receiving data; therefore has a chance of containing data previously sent or received -- encrypted or not, such as HTTP headers, cookies, HTML content, POST forms, etc. It doesn't matter if your application exited, or if it's still running, even if it's on the same box. Protected mode and the secure memory manager on modern OSes makes what you are suggesting quite infeasible --- different processes cannot directly read each other's memory, AND on modern OSes, memory pages are always initially zero'd out some time after allocation to a process -- whenever the malloc() memory manager needs to call brk() to expand the program's data size, before the application can actually successfully read any newly mapped memory pages, the operating system will zero any existing content of that memory, just as it would do when reading unallocated sections of a file (instead of showing previous disk contents). The vulnerability is related to re-used memory pages within the same process. It also does not help that OpenSSL has its own wrapper around malloc() And instead of using the standard system libraries for memory allocation, apparently uses a high-risk memory allocation policy, that maximizes the exploitability of vulns like the Heartbeat extension issue, and prevents security mitigations from working that would otherwise be effective.: see: http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf vv. http://article.gmane.org/gmane.os.openbsd.misc/211963 Generally free() doesn't actually release pages from a program back to the OS, the freed memory just becomes available for a later malloc within the same program. This is also what OpenSSL's homebrewedmalloc implementation does buffers not needed anymore are not actually free()'d; OpenSSL reuses buffers later to satisfy future internal memory allocation requests, bypassing the system's malloc()/free() the entire time. isn't really something that you can be sure of though. I'm not even sure if it's done in most crypto apps aside from gpg. OpenSSL is double-faulted here for both not checking the length and not zeroing the memory on malloc**. -- -JH
