Felix, On 11.11.2014 12:50, Felix morack wrote: > Like so many people i am still running 4.12 due to the "hardening" > issues. yes, i reported a bunch of them back when we first started, and > yes i have since tested all versions up to 4.18. We are now nearing a > point where i cant deploy 4.12 anymore due to formal security > regulations, so i have to get serious about this now.
We're still working on improvements, though I don't know your current show stopper. It was never our intention to cause trouble for so many users (much less by now, but still too many), yet it turned out that due to unbelievably insecure design of many applications/tools/libraries (and the whole operating system) it's an unavoidable consequence of plugging security holes for good. > I am therefore looking for a detailed, technical description of this new > 'feature' and why devs think it is necessary. Sorry, all we're allowed to do is refer to the corresponding CVEs (which were formally created by Oracle, but in reaction to external reports). We can't give additional details, or have influence on the details mentioned in the CVEs. > Yes, i have the code, but a high level reasoning would be very helpful, > especially what has changed with version 4.12. Specifically i am looking > for documentation "between" the source code and the manual. Does such a > documentation exist in public? Any technical discussion of it perhaps? Unfortunately the high level reasoning would be the blueprint for exploiting all related security holes, even the ones not explicitly reported. We're not allowed to do that. > Background is that i am think about deploying my own custom build with > hardening disabled. Which is pretty insane, but there is no chance in > hell anything post 4.12 ends up even in proximity to systems whose > stability i am responsible for. This will make these systems vulnerable to a whole range of attacks, which ultimately is your decision. > tb > > p.s. does vmware have such a feature? How do they handle it? Ask VMware... we have enough to do with VirtualBox. We don't spend time to investigate if their (closed source) products are susceptible to the same or similar attack vectors. Klaus _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
