21–30 of 37 posts
Blows my mind that there’s people who figure this stuff out. Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff? How often does discovery or research like this lead to a dead end?
I just noticed that they renamed Project Fi to just Google Fi. When I first saw this post, due to Project in the name I thought it was Google Fi. Good on them for changing the name. Maybe it's a sign that Google will be more consistent in their naming in the future.
I'm surprised they're still using a blogspot subdomain . Something like zero.google or projectzero.google would work (with redirects for existing links)
Blows my mind that there’s people who figure this stuff out. Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff? How often does discovery or research like this lead to a dead end?
It's completely amazing to me too. As I understand it, one of the tools that the security research community uses is fuzzing ( https://en.wikipedia.org/wiki/Fuzzing ). I can at least understand how this sort of technique would help generate some leads. I'd recommend the Security Now podcast by Steve Gibson if you're interested in this sort of thing. He does a great job explaining many of the exploits out there.
I constantly get a kernal panic on multiple machines under heavy load of the sort of trying to interlock destroyed mutex from within, according to the backtrace, com.metakine.handsoff.driver. I'm wondering if it's exploitable.
I constantly get a kernal panic on multiple machines under heavy load of the sort of trying to interlock destroyed mutex from within, according to the backtrace, com.metakine.handsoff.driver. I'm wondering if it's exploitable.
I constantly get a kernal panic on multiple machines under heavy load of the sort of trying to interlock destroyed mutex from within, according to the backtrace, com.metakine.handsoff.driver. I'm wondering if it's exploitable.
Is that a third party kernel extension? Sounds like a buggy one if so, and if it’s this " rel="nofollow">https://www.oneperiodic.com/products/handsoff/> then it might be lessening security instead of increasing it.
Blows my mind that there’s people who figure this stuff out. Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff? How often does discovery or research like this lead to a dead end?
It would be interesting to see how many of these bugs would be possible if an operating system written in Rust would be used. I would treat any code allocating / deallocating / moving / locking memory by hand instead of using higher level constructs unsafe now that we know that it's possible to automate checking safety of the operations.
The moment I saw article was about a bug in native code I knew there would be a comment like
“I wonder if Rust could have helped here?”
Blows my mind that there’s people who figure this stuff out. Do they just spend their day to day time at work attempting all sorts of variations of this kind of stuff? How often does discovery or research like this lead to a dead end?
They tend to be really smart and motivated people. For example, http://lcamtuf.coredump.cx/gcnc/ is not just a good guide to CNC, it's an amazing guide where you realize he learned half the unwritten rules just by thinking about them. http://lcamtuf.coredump.cx/rstory/ for the robots.