Nov 27, 2012

Here's all the crapware that comes with new Windows 8 PCs | ITworld

Great little fact that has always bugged me. One more reason to use a Mac.

Here's all the crapware that comes with new Windows 8 PCs | ITworld:

The PC Decrapifier Wipes Unwanted Junk | The PC Decrapifier

The PC Decrapifier Wipes Unwanted Junk | The PC Decrapifier:

Nov 6, 2012

Researcher advises against use of Sophos antivirus on critical systems

Any exploit of any piece of software that remains un-patched is dangerous. If you have software that's deployed on an enterprise level, it makes it that much more important to have layers of security and excellent patching processes for ALL of your software.

If Sophos fails to patch exploits in a timely matter, that's a different story.

From Slashdot.


Antivirus provider Sophos has fixed a variety of dangerous defects in its products that were discovered by a security researcher who is recommending many customers reconsider their decision to rely on the company.

"Sophos claim that their products are deployed throughout healthcare, government, finance, and even the military," Tavis Ormandy wrote in an e-mail posted to a public security forum. "The chaos a motivated attacker could cause to these systems is a realistic global threat. For this reason, Sophos products should only ever be considered for low-value non-critical systems and never deployed on networks or environments where a complete compromise by adversaries would be inconvenient."

A more detailed report that accompanied Ormandy's e-mail outlined a series of vulnerabilities that attackers can exploit remotely to gain complete control over computers running unpatched versions of the Sophos software. At least one of them requires no interaction on the part of a victim, opening the possibility of self-replicating attacks, as compromised machines in turn exploit other machines, he said. The researcher provided what he said was a working exploit against Sophos version 8.0.6 running Apple's OS X. Attackers could "easily" rewrite the code to work against unpatched Sophos products that run on the Windows or Linux operating systems, he said.

A post published to Sophos's Naked Security blog around the same time Ormandy released his report thanked the researcher for privately disclosing the vulnerabilities so they could be fixed before attackers have the knowledge required to exploit them.

"The work of Tavis Ormandy, and others like him in the research community, who choose to work alongside security companies, can significantly strengthen software products," the post stated. "On behalf of its partners and customers, Sophos appreciates Tavis Ormandy's efforts and responsible approach."

The Sophos post detailed eight fixes that were released from 42 days to 55 days after Ormandy privately brought them to the attention of Sophos engineers. For his part, Ormandy concluded that the amount of time it took to release the patches was excessive.

"Sophos simply cannot react fast enough to prevent attacks, even when presented with a working exploit," he wrote. "Should an attacker choose to use Sophos Antivirus as their conduit into your network, Sophos will simply not be able to prevent their continued intrusion for some time, and you must implement contingency pans to handle this scenario if you choose to continue deploying Sophos."

A security researcher at Google, Ormandy stressed that his report and comments were entirely his, and not those of his employer.

With marked improvements in the security of browsers and Adobe's Reader and Flash applications, it wouldn't be surprising for attackers, particularly well-funded ones targeting a specific corporation or government agency, to turn their attention to AV programs. The detailed interactions AV programs have with browsers and sensitive operating system regions means there's plenty of opportunity.

It's unclear if Ormandy has analyzed the security of other antivirus products so he can arrive at an assessment of how they compare to Sophos. He didn't respond to an e-mail seeking comment for this post.

Why Google Went Offline Today and a Bit about How the Internet Works

Interesting Read from CloudFlare.

Today, Google's services experienced a limited outage for about 27 minutes over some portions of the Internet. The reason this happened dives into the deep, dark corners of networking. I'm a network engineer at CloudFlare and I played a small part in helping ensure Google came back online. Here's a bit about what happened.

At around 6:24pm PST / 02:24 UTC, CloudFlare employees noticed that Google's services were offline. We use Google Apps for things like email so when we can't reach their servers the office notices quickly. I'm on the Network Engineering team so I jumped online to figure out if the problem was local to us or global.

Troubleshooting

I quickly realised that we were unable to resolve all of Googles services — or even reach 8.8.8.8, Googles public DNS server — so I started troubleshooting DNS.
$ dig +trace google.com

Here's the response I got when I tried to reach any of Google.com's name servers:
google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 164 bytes from 192.12.94.30#53(e.gtld-servers.net) in 152 ms ;; connection timed out; no servers could be reached

The fact that no servers could be reached means something was wrong. Specifically, it meant that from our office network we were unable to reach any of Googles DNS servers.

I started to look at the network layer, see if that's where the problems lay.
PING 216.239.32.10 (216.239.32.10): 56 data bytes Request timeout for icmp_seq 0 92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217): Time to live exceeded

That was curious. Normally, we shouldn't be seeing an Indonesian ISP (Moratel) in the path to Google. I jumped on one of CloudFlare's routers to check what was going on. Meanwhile, others reports from around the globe on Twitter suggested we weren't the only ones seeing the problem.

Internet Routing

To understand what went wrong you need to understand a bit about how networking on the Internet works. The Internet is a collection of networks, known as "Autonomous Systems" (AS). Each network has a unique number to identify it known as AS number. CloudFlare's AS number is 13335, Google's is 15169. The networks are connected together by what is known as Border Gateway Protocol (BGP). BGP is literally the glue of the Internet — announcing what IP addresses belong to each network and establishing the routes from one AS to another. An Internet "route" is exactly what it sounds like: a path from the IP address on AS to another.

BGP is largely a trust-based system. Networks trust each other to say which IP addresses and other networks are behind them. When you send a packet or make a request across the network, your ISP connects to its upstream providers or peers and finds the shortest path from your ISP to the destination network.

Unfortunately, if a network starts to send out an announcement of a particular IP address or network behind it, when in fact it is not, if that network is trusted by its upstreams and peers then packets can end up misrouted. That is what was happening here.

I looked at the BGP Routes for a Google IP Address. The route traversed Moratel (23947), an Indonesian ISP. Given that I'm looking at the routing from California and Google is operating Data Centre's not far from our office, packets should never be routed via Indonesia. The most likely cause was that Moratel was announcing a network that wasn't behind them.

The BGP Route I saw at the time was:
tom@edge01.sfo01> show route 216.239.34.10 inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden) + = Active Route, - = Last Active, * = Both 216.239.34.0/24 *[BGP/170] 00:15:47, MED 18, localpref 100 AS path: 4436 3491 23947 15169 I > to 69.22.153.1 via ge-1/0/9.0

Looking at other routes, for example to Google's Public DNS, it was also stuck routing down the same (incorrect) path:
tom@edge01.sfo01> show route 8.8.8.8 inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden) + = Active Route, - = Last Active, * = Both 8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100 AS path: 4436 3491 23947 15169 I > to 69.22.153.1 via ge-1/0/9.0

Route Leakage



(Image Credit: The Simpsons)

Situations like this are referred to in the industry as "route leakage", as the route has "leaked" past normal paths. This isn't an unprecedented event. Google previously suffered a similar outage when Pakistan was allegedly trying to censor a video on YouTube and the National ISP of Pakistan null routed the service's IP addresses. Unfortunately, they leaked the null route externally. Pakistan Telecom's upstream provider, PCCW, trusted what Pakistan Telecom's was sending them and the routes spread across the Internet. The effect was YouTube was knocked offline for around 2 hours.

The case today was similar. Someone at Moratel likely "fat fingered" an Internet route. PCCW, who was Moratel's upstream provider, trusted the routes Moratel was sending to them. And, quickly, the bad routes spread. It is unlikely this was malicious, but rather a misconfiguaration or an error evidencing some of the failings in the BGP Trust model.

The Fix

The solution was to get Moratel to stop announcing the routes they shouldn't be. A large part of being a network engineer, especially working at a large network like CloudFlare's, is having relationships with other network engineers around the world. When I figured out the problem, I contacted a colleague at Moratel to let him know what was going on. He was able to fix the problem at around 2:50 UTC / 6:50pm PST. Around 3 minutes later, routing returned to normal and Google's services came back online.

Looking at peering maps, I'd estimate the outage impacted around 3–5% of the Internet's population. The heaviest impact will have been felt in Hong Kong, where PCCW is the incumbent provider. If you were in the area and unable to reach Google's services around that time, now you know why.

Building a Better Internet

This all is a reminder about how the Internet is a system built on trust. Today's incident shows that, even if you're as big as Google, factors outside of your direct control can impact the ability of your customers to get to your site so it's important to have a network engineering team that is watching routes and managing your connectivity around the clock. CloudFlare works every day to ensure our customers get the optimal possible routes. We look out for all the websites on our network to ensure that their traffic is always delivered as fast as possible. Just another day in our ongoing efforts to #savetheweb.

Microsoft Is Turning Kinect Into a Narc

This really creeps me out. From Gizmodo.

Kinect is tons of fun. Have you ever played Dance Central 3? Great game. But according to a newly discovered patent, the Xbox add-on is also maybe spying on you, which is totally not cool, man.

This very big brother-y piece of intellectual property—Content Distribution Regulation by Viewing User—uses Kinect's camera to count the number of people in the room and in some cases, identify who they are. This "consumer detector" will charge you licensing fees based on how many bodies are present, and could even stop playback to collect on you if it detects more humans than you've paid for.

Sorry if you have a baby face, because the tech could also check on ages and cut off mature content if the system doesn't think you're old enough. God, Kinect. Such a tattletale! [USPTO viaGeekwire via BetaBeat]