There should be recalls from more manufacturers. Someone I know purchased a surveillance camera with a major brand name (Samsung) from Costco [0] just a few weeks ago that gave me a root shell by simply telneting in as root with no password and no way to reliably set a root password or disable telnet. It was returned the following day. Last I checked, Costco is still selling it. This problem isn't confined to cheap Chinese cameras you can buy online. Vulnerable devices are being sold at major American retailers and they are still on the shelves.
> probably the more likely scenario is that some insider leak some of the distributors private keys which would allow certain releases to be cracked - but would likely also trigger key roll over.
It could also be the case that someone leaked the plaintext symmetric key(s) for this specific movie's DCP. If someone gained access to private/secret keys on a compromised DCP player somewhere, it'd be smarter to leak symmetric keys for individual movies to avoid detection.
I think that's because OCI currently only has a specification for the runtime, not the distributable image. But it seems like as of a few weeks ago, work is underway to standardize the distributable image as well: https://github.com/opencontainers/image-spec
Yep, I agree and that's where I install stuff on everything other than OS X. One distinction though, I think, is that most of the stuff I install on OS X I don't want to be available system-wide. I'm (typically) not using Homebrew to install daemons that run all the time or things that serve critical system/network functions, so I've never seen a reason to make them available to the entire system. I agree that goes against the Unix way but I started preferring this way of using Homebrew after I had similar problems upgrading and even updating OS X.
Also, what if for some reason a single machine is shared by two people and they need different versions of some programs installed with Homebrew? Installing everything in /usr/local isn't going to look like a good idea then.
Mostly because of my (perhaps irrational) OCD in not wanting to touch global system paths or files, even though under FHS /usr/local is where you're supposed to install manually-managed libraries and binaries. I believe Homebrew likes to have its path owned by you instead of root, so I think it makes more sense to have stuff that's going to be owned by me to be in my home folder rather than /usr/local.
I'm curious to know if there's a reason everyone installs Homebrew in /usr/local (other than it being the default installation path). I've always chosen to install it in ~/.homebrew and haven't had any problems. Everything I install with Homebrew seems to handle an alternative prefix without issue.
Why did Stellar decide on using Facebook accounts to enforce the one account per person rule, instead of something better like mobile numbers? There are more people with cell phones than there are with Facebook accounts. Acquiring large batches of phone numbers to game the system is harder since it costs money and is more easily detectable.
Even if this guy isn't gaming the system with fake Facebook accounts, I'm sure others already are.
Sure, they wouldn't be able to proxy all HTTP requests through their own servers like they're doing now, but they'd still be able to do MITM attacks at the IP level. They're already messing with routes to Google Public DNS IPs so they could just as easily mess with routes to YouTube's IPs. I don't think DNSSEC is the solution in cases like this. Somehow getting everyone to use SSL for everything is a much better solution in my opinion.
You're right. Maybe if they turned on and required SSL for everyone visiting www.youtube.com and added www.youtube.com to Chrome's preloaded HSTS list and somehow got everyone to use Chrome. Sadly, this probably won't happen, but DNSSEC adoption probably won't happen either. Even with DNSSEC, they could still do deep packet inspection on HTTP traffic going to YouTube IPs and initiate MITM attacks that way.
Can you do a traceroute to 8.8.4.4? If it's actually reaching Google's network, then yeah, they're doing deep packet inspection on DNS traffic. If not, they're probably just routing 8.8.4.4 to a DNS server they control.
If their goal is to manipulate traffic to www.youtube.com (probably to block access to certain videos), another solution would be for YouTube to require SSL for all connections coming from Turkish IPs. Of course, this wouldn't work if they got some Turkish (or other) CA to sign a bogus www.youtube.com certificate.
EDIT: As lawl points out, trying to require SSL on www.youtube.com won't work either, since they could just do an sslstrip type attack.
Good point. I just checked that file ever since it was open-sourced in 10.8 and it stays exactly the same throughout all of 10.8.x (10.8 - 10.8.5) and only changes in 10.9. (You can check for yourself here: http://opensource.apple.com/)
It doesn't seem like what you said is the case here but obviously we're still missing changesets that may have been committed between 10.8.5 (Security-55179.13) and 10.9 (Security-55471). It'd be really interesting to do a git-blame on that file.
EDIT: Nevermind, that file wasn't open-sourced in 10.8. It's actually really old. (Look for directories starting with libsecurity_ssl in pre-10.8 OS X versions.) Didn't find anything particularly interesting in the old versions though.
FWIW, here's what I got on an Ubuntu 12.04.3 server running on my LAN. It looks like we should be fine with the defaults on Ubuntu at least. (Obviously always a good idea to use ufw/iptables to block everything you don't need exposed so you don't have to worry about stuff like this).
Before installing ntp (from another host on my LAN):
> Also, web servers might want to consult NTP servers now and again.
CloudFlare doesn't host web servers for their customers. They forward HTTP/HTTPS requests to origin servers outside of their network (or serve from their cache). I don't think the DDoS traffic actually hit any of their customers' origin servers (assuming origin server IPs are not known by the attackers). But yeah, it still means CloudFlare's incoming pipes being hit with 400Gbps of traffic before they're able to filter anything.
The summarization tech isn't owned by Summly. It's owned by SRI International and was licensed to Summly. Maybe a large chunk of the reported $30 million was actually used to acquire that technology from SRI?
[0] http://www.costco.com/Samsung-SmartCam-HD-Plus-1080p-Wi-Fi-I...