Not blocked necessarily, but if they want to leverage a stolen token, they’re now forced down a more difficult and highly visible pathway.
You can imagine anomaly detection along the lines if “hey your rails app just made a type of request that it has never made before”, but even just monitoring the metrics of the proxy could tip you off if something is going on.
Ignoring MD5/image format-specific collision realities, theoretically an attacker could submit a contraband image that collides with a valid, allowed image they may want to remove.
When action is taken on the first image, the collided image could also be censored.
Not with current technologies. There is a big difference between creating an image that collides with a specific target hash and just making two images that collide when you control both. The former is not currently possible, and the latter is.
That being said, you could probably create a pair of colliding images, give one to a news outlet or something, then later post the second (presumably banned) one. The app would on short notice need to decide between banning neither or banning both.
> That being said, you could probably create a pair of colliding images, give one to a news outlet or something, then later post the second (presumably banned) one. The app would on short notice need to decide between banning neither or banning both.
Yeah they did this - except the contraband was automatically recognised and both images were banned via hash.
I'm a heavy user of the Twitter web and iPhone clients, and I'm not sure what you mean by "live updates" tab. Is that something in TweetDeck or another client?
If you (or parent poster ~TheTruth1234) found this unwanted, wouldn't unfollowing or blocking the source accounts be an adequate remedy?
(It is a embarrassing mess, but par for Twitter's lackadaisical approach software quality, that Twitter web often ignores their own settings' "don't autoplay" toggle, and has for many months.)
Well, it's not obsolete - more incomplete. OpenBSD has supported ipv6 natively for a long, long time.
Additionally, with a "home/office" router, there's many ways that IPv6 may be implemented by their ISP (e.g. static configured prefix, DHCPv6, prefix delegation etc...) all which require specific configuration on the WAN and LAN side to make it work.
So, I agree, but splitting that particular part into a different FAQ/walkthrough is going to be a better approach.
Not 100% sure, but I think this is to mitigate exploitation of UAF (Use After Free) flaws.
Adding an unpredictable delay in between when an application frees some memory, and it becomes available for reuse elsewhere will likely reduce the window of vulnerability where an exploit may be able to leverage the issue.
OpenBSD has happily run as a guest for a long time now, with various virtio drivers being added some time ago. Solutions like virtualbox and xen reach far into the system and are still a no-go on OpenBSD.
vmm on the other hand is a very literal OpenBSD implementation of a hypervisor. Minimal cruft means very little device emulation, virtio support only etc... The code is simple and readable[1], as opposed to other monstrosities.
I would take a punt and guess that the reason OpenBSD hasn't had a hypervisor is that a) all of the current solutions were inappropriate, and b) nobody had the time/effort to implement an appropriate one.
If you actually read the thread he was reacting to the premise that: as a secure operating system, OpenBSD should implement virtualisation (in this case, Xen) due to its security benefits.
A premise which he rightly shat directly on, and is his statement is completely congruent with the presence of a VM hypervisor in OpenBSD.
"OpenBSD should implement virtualisation (in this case, Xen) due to its security benefits."
A specific answer that only took a day to form.
"If you actually read the thread"
Still this again, though. That's three people whose position is that anyone wanting to know OpenBSD's position on virtualization should spend 20m-1hr digging through threads like that and many dozens of hours watching video presentations/interviews. Just in case the answer's there. That's quite unreasonable given one link to a definitive answer on a mailing list, site, etc is all it would take. It's not a one-off thing as this topic comes up endlessly with them having the same response minus some exceptions.
So, given them acting that way, it's a reasonable default for outsiders to assume they didn't give a crap, got way behind on virtualization, cite comments like that just to save time, and finish by adding they're finally doing something. It's actually more effort than OpenBSD supporters put in those discussions. At least one had the wisdom to send me a video with Theo straight up saying it wasn't a priority. QED on whole topic. See how easy that was?
> anyone wanting to know OpenBSD's position on virtualization should spend 20m-1hr digging through threads like that
Okay, okay. Personally, I think the fact that OpenBSD did not support any of the current virtualisation solutions, and now have an appropriate one in the works says a lot about their position.
And, frankly, what use is an organisations "position" on VM hosting to a user? It either supports it or it doesn't, and if you don't plan on developing it the reasons don't really matter.
EDIT: I'm also going to point out that mailing list posts in general rarely stand on their own, and exist within a context.
"Personally, I think the fact that OpenBSD did not support any of the current virtualisation solutions, and now have an appropriate one in the works says a lot about their position."
It's ambiguous far as past is concerned. Two possibilities are (a) they didn't care for longest but caved on the issue or (b) they wanted it, waited for a solid codebase that never showed, and finally did one of their own. All I can tell is that it matters to them now.
"And, frankly, what use is an organisations "position" on VM hosting to a user? It either supports it or it doesn't, and if you don't plan on developing it the reasons don't really matter."
Not true. Very few develop for Linux or FreeBSD vs number of stakeholders. Nonetheless, many features non-developers would want came about because people needed it or were talking about it. I agree with you for OpenBSD specifically, though, as they've been clear about "code it if you want it so bad."
"EDIT: I'm also going to point out that mailing list posts in general rarely stand on their own, and exist within a context."
True, too. Probably best way to apply that is to just not quote mailing lists if it's a huge conversation. I only quote or back those references because later interviews corroborated them a bit for virtualization in general. We certainly shouldn't just grab things off mailing lists without a context, though.
Eh, I think you're being overly harsh. He expresses strong disdain for the whole concept on the x86 platform, and it's not unreasonable to extrapolate that to a "this is such a bad idea, so dangerous that we won't supply such an inherently broken thing".
It's perfectly reasonable to extrapolate his views against virtualization to a general case given these two lines:
"x86 virtualization is about basically placing another nearly full kernel, full of new bugs"
"You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
He clearly hates x86 more than most but his point applies in general. He's not the only one whose made it and there's truth in it. It's why high assurance virtualization... well.. applied high assurance to those parts haha. Also, why attempts at robust, resource virtualization typically pushed as much complexity out of the hypervisor as possible upward to the OS's that were on less privileged rings or capability-isolated depending on which system.
However, I said then he was wrong because the hypervisor and even VMM functions are less complex than a whole OS. The past examples showed they can be implemented very simply. We got further confirmation with the NOVA microhypervisor, OKL4 platform, separation VMM's (eg LynxSecure), and so on. People are still finding kernel flaws in the UNIX-like OS's due to architecture, language used, and intrinsic complexity. Many less problems in aforementioned software.
The selective reading might be on you although I'm thinking it's how it's worded rather than readers' fault. Anyone reading your link would catch this line:
"But instead we have many uneducated people saying: 'Yes, it increased hardware utilization, and it improved security too'. And that's complete and utter bullshit."
Whereas, as I referenced, many VMM systems did increase security via isolation with something simpler than the arbitrary OS and monolithic software contained. Lowest TCB I saw with minimum necessary features was in 50-100KB range. What's OpenBSD's + VMM's TCB size, again? :P
Taking 2nd link into account, it still has that thing about it claiming virtualization can't improve security posture, prevention or recovery. That was repeatedly proven false in academic and production systems with some surviving pentests by pro's that regularly tore through UNIX OS's and commercial fodder. So, his statement against security potential of virtualization is "complete and utter bullshit."
Note: As with other link, it becomes true if one is talking about common offerings, esp on x86.
I'm going on what an OpenBSD supporter or developer... not sure which... said to me in a prior discussion here. I brought up Theo's rant against x86 virtualization. Others showed up to clarify a bit. One posted a video interview where Theo pretty much said they hadn't cared about that and some other things that the market was big on. However, that they'd finally need to adapt and pay more attention to such stuff, esp virtualization. Now, there's a VMM.
So, given prior conversation, I thought of their recent efforts to do what they were against or not interested in to be a compromise between how they wanted it and what OpenBSD needed for more use in market. The first of hopefully many which might bring more coders and capabilities to the project.
I'm a supporter, mailing list reader and send in occasional patches here and there.
Whenever Theo speaks about OpenBSD he uses the words "research OS". For every developer this might be different, but it's still worked on a From-Developers-For-Developers basis. If anybody else can use it then that's also good. If you want to change it, send patches. Don't demand features, send patches. Don't know how to setup things, read manpages and the faq, if it's not in there find out for yourself and then send patches for the documentation.
Most things are based on a need a developer once had and couldn't live without. That changed a bit since the OpenBSDFoundation got some money and is now paying for development time for features nobody dared to touch so far... like VMM (at least that's what I heard)
For me OpenBSD is not about market share but about best practices.
On the flip side, if they were offering TLS services to these sites, they're literally man-in-the-middling encrypted comms to those sites. And in scope of US law-enforcement/intel collection.
Might be that they were asked to continue to provide services.
Well PV domU support is more invasive, but HVM is not (it is just like kvm), and Amazon supports both. The middle ground is the pvhvm mode which requires some Xen drivers for additional support, rather than the virtio drivers that kvm/bhyve use - Xen has a different driver model.
Not blocked necessarily, but if they want to leverage a stolen token, they’re now forced down a more difficult and highly visible pathway.
You can imagine anomaly detection along the lines if “hey your rails app just made a type of request that it has never made before”, but even just monitoring the metrics of the proxy could tip you off if something is going on.