1) Metasploit isn't a graphical exploit; it's a Perl shell, very well done, that made exploit development and deployment a far more reliable endeavor.
2) They're pretty damn motivated -- not perfect, but way more than I've seen any corp. Like I said -- the "intro to security lecture" (people WILL find your holes, you WILL get attacked, etc) just didn't happen.
3) 13 open reqs for just one consultancy I know of that's got security auditing gigs at MS. Yeah.
4) I hadn't made the link between customer service and security. You're completely right about it needing to be a cultural element.
Lesse...I was there, Dug Song was there, K2, Shok, and Dino were there...a hacker con it most certainly was, just with a rather different audience than normal.
It wasn't so much the question, as the unexpected nature of it. I'd just finished talking about very different things -- video over DNS, backtunnelling through dual-hosted name servers, etc -- and it had been about 20 minutes since I'd mentioned that, *if* someone asked, I'd show what was wrong with MD5.
No matter. This guy -- I had no idea who he was at the time -- heard something he needed to precisely understand, and got his answer at his first opportunity.
It's kind of cool that senior management at Microsoft a) showed up at an internal hacker con and b) knew enough to not only understand what I was talking about, but was interested enough to demand more.
Dude. Have you met anyone in senior management? There's a reason so many people relate to the Dilbert PHB.
What would you think if almost all the code on your system was assembled by Microsoft -- even the third party stuff?
Strange. Bad. Awful.
But it's the reality with RPM, or even Apt/Emerge. The Linux distributions really have limited how much stuff the average user installs randomly from the net. But it's a temporary thing...Spyware for Linux isn't worth developing, because there aren't enough non-geek eyeballs to sell.
It's overall a pretty cool article, but the comparison I had made when talking to Ina was that spyware-assaulted Windows vs. the always-perfect nature of a fresh Knoppix CD is a surprisingly tough contest, and that people may be willing to give up their own ability to customize their system in return for the ability to protect the basic functionality of their system.
That's the point -- there weren't just network programmers, or compiler writers, or the reps from the security business unit who'd go to Black Hat anyway. People from across the organization showed up.
So the last event at Blue Hat was a panel with all the speakers, answering general questions from the moderator and the audience. I ended up relaying Conover's experience regarding 18/20 senior managers knowing about heap overflows -- and, no joke, one of the heads of their Security Business Unit stands up and says, "Ah. So who exactly didn't know about heap overflows?"
A number of large companies end up being managed by professional managers who know nothing about the field they're involved in. MS is many things...definitely not one of those.
Forget about deep dives -- this could potentially be _very_ cool for diving approximately five to fifteen feet. Just being able to jaunt around a pool, or explore shallow water coral reefs, without having to maintain scuba gear would be rather cool. I imagine a snorkel that doesn't actually need to reach air.
If it was stable enough, it could even be useful for life preservers.
Interesting failure modes. We can resolve them as such:
1) If the phone never loses power, it can be presumed it did not move. So the cached previous location can be restored.
2) If the phone does lose power, and is given a new address -- plugging it in can cause it to ring. Then the person, already at the phone, explicitly knows 911 will work. Nice.
A bigger problem comes from -- just how much accuracy is required? How much do you want to demand people tell you when you plug in the phone?
1) The first time you make an outgoing call, you are asked to enter the zip code or city/state (voice recognition) you're located in. That information is tied to your phone, and your/24 subnet.
2) The first time you make an outgoing call on a new/24 subnet, you're asked once again for location information.
3) If many users have different locations from the same/24 subnet, calls to 911 are prefaced with "You are being directed to 911 operations at 'foo'. Press zero if you are not located here."
I'm a packet hacker type, and I know all about IP geolocation databases, but they're the wrong approach. I'm sitting here in Vancouver right now and all my traffic comes from either Santa Clara (where my home network is) or New Jersey (where my company network links live). If you want to know which 911 to give me -- *ask*.
That the result will be a very accurate geolocation database is just gravy.
Note, I'm not saying this is how things _might_ be solved. I can imagine geolocation as a last ditch bonus just in case. But short of putting a cell transponder w/ GPS in every VoIP device -- something we can't even get in cells -- utterly silent 911 tracing ain't happening.
A problem with the engine can take down the plane.
FAA policy is that plane crashes are very, very bad. Absurd amounts of procedures are created to prevent plane crashes. Liability for plane crashes can be massive.
The engine manufacturer can't rule out that third party tools would find different problems than their own; the whole point of you owning this third party device is that, as a pilot, you've made a judgement call that the manufacturer's supplies were insufficient. Your call is being overridden by an overprotective manufacturer, treating you as an enemy to be obfuscated against.
If you crash -- it cannot be ruled out that you might not have if you had this extra information. All the FAA needs to say is -- those who interfere with pilot judgement may face consequences for such decisions -- and the potential liability will outweigh anything else.
"Can you say, with absolute certainty, that no third party fault detector would have found the problem with your engine?" "No, but..." "So, you intentionally embarked on a development program that hid problems with your engines. Thank you."
This exchange, vaguely hinted at by FAA, would be quite enough.
No, it does not make complete sense. It does if you are a freenode-using, FSF-supporting GPL Zealot, but under any other condition it does not make since (i.e. the real world.).
*shrugs* I don't understand why people think the GPL is so onerous. Have you seen the tripe that gets put into EULAs? The GPL specifically says you can do whatever you want with this code, including merge it into your own projects and share nothing of them. It's only when you merge _and_ distribute that its requirements pop up, and if you don't like them -- well, negotiate something better.
You don't link syscalls. Syscalls are re-enterant entrypoints into kernel namespace, and their shims (AND _syscall()) are provided by glibc, NOT the kernel.
You need to use glibc to use the kernel? All those people with dietlibc will be very surprised to hear. The kernel has a set of numerically identified interfaces, each of which is triggered by interrupt. There are any number of ways of feeding these interfaces, but make no mistake -- it's kernel, not libc.
*shrugs* No, it makes complete sense. Copyrights control distribution, not use. If the use of a piece of code is to output some content, push something on screen, or whatever else, then anything can drive it -- open source, closed source, or whatever. It's only when you distribute code that insinuates itself at the source level that you need to share the code you added.
The Linux exception comes from the fact that you directly link chunks of Linux into your own modules when you create kernel modules. You are correct that it's ludicrous to consider the generic kernel syscall interface living under the same exemption.
To be clear -- using dshow filters, piped executables, and so on is fine by GPL; you're just not allowed to link the code into your application. It looks like they modified the GUI tools, though, without releasing source. That's not allowed.
The problem is that we have entire architectural pipelines -- too complex for a simple DSP -- that don't generally support the level of very high speed reactions and changes that reality itself exhibits in response to our actions. Linux, with the new pre-emptible kernel code developed for low latency audio, does show some very nice potential (sub-ms scheduling is good). But fitting the position/draw loop into what's necessary is still a challenge.
The images in front of your eye need to be in motion _while_ you're moving your head. You're right, they don't necessarily need to be blurred, but saccade will be suppressed if you've got this stable picture in front of you when there's supposed to be a blur initiating.
I've experienced this on HMD's. Takes a bit to recognize what's wrong.
What's wrong with VR? Hmm, this was the first tech subject I ever investigated in depth, and it's kind of amusing it hasn't gotten much better after all these years. I was just ranting about this a little while ago, but I'll go more in depth here:
There are some real problems with latency. Modern operating systems have a really hard time with the idea that there are hard deadlines that must be met on a sub-100ms basis. Even some graphics programmers hold onto the myth that 30fps has anything to do with how fast the human eye can detect motion. The reality is that we detect different faults at different rates, but anything that's tied to our own sense of motion has to be accurate at somewhere around the frame rate of touch.
The frame rate of our haptic senses is something on the order of 3000 frames per second.
That doesn't mean you need to update a display at 3000fps (though ironically enough, that's approximately the frequency of the fluorescent backplane on an LCD), but it does mean that if you're trying to show someone something at the same time a touch simulator is telling them they are, frames need to interrupt-updated at a speed that even the core operating system has trouble handling.
What do I mean by touch simulators? Nothing so complex as this per-finger force feedback weirdness that pulled back on each finger as I touched a virtual cockpit back at SIGGRAPH. No, anything involving a head-mounted display and a position detector is a touch simulator; the "feel" comes from within your head and neck and the reaction is to be visually accompanied by a display of motion.
But the display is always, always, always late! Look at the monitor. Now move your head and eyes, look at whatever's 90 degrees off to the right. For a noticable sub-second interval, you went blind, so that your brain would not need to contend with this blurry streaky mess. To be immersive, VR systems need to detect your motion, synthesize the appropriate blur-frames, and (hardest of all) have a convenient stable frame in front of you as you're escaping motion-blindness.
Everything head-mounted fails this just brutally.
There are vague successes in VR, of course. Driving simulations work fantastically, but it's not like driving is a massively natural feat for our brains to have adapted to in the first place. Screens on every window clean up the above quite neatly. And the phobia work functions because the fears operate on such a low level that your brain isn't able to employ resources such as "heh, that spider's moving wrong". These are useful and impressive successes, but in terms of general purpose "you are elsewhere" mechanisms -- until latency is dealt with appropriately, this will continue to be broken tech.
Funny to see this code; I was just pinging the developers of C Global Surveyor (a vaguely similar tool that operates on C/C++ code instead of Java) to see if I could get access to their work. I didn't get a reply, but hopefully Java Pathfinder will give them the cover they need...seriously, CGS looks absolutely brilliant.
Oh, high latency issues have been studied for years (see the TCP Performance Enhancing Proxies, like SkyX). There's precious little in the open source world that implements such things, though, and it's needed.
Too bad there's no code for this Linklider out there...it looks quite cool. Thanks!
I looked at DTN earlier today; they've got some good ideas and I want to play with their code. But they seem much more tied into ad-hoc/disconnected operation than anything to do with extreme-high-latency (but large pipe) links. Plus I couldn't find anything that dealt with rate adaptivity, which is a wildly difficult problem without rapid feedback.
I *am* happy to see some code, don't get me wrong:) It'll hopefully inform my own work with Fragile Router Protocol (my system that gets ~65K/sec out of DNS).
Slashdot Mirror
Wait, which Joey is this???
Lesse...
1) Metasploit isn't a graphical exploit; it's a Perl shell, very well done, that made exploit development and deployment a far more reliable endeavor.
2) They're pretty damn motivated -- not perfect, but way more than I've seen any corp. Like I said -- the "intro to security lecture" (people WILL find your holes, you WILL get attacked, etc) just didn't happen.
3) 13 open reqs for just one consultancy I know of that's got security auditing gigs at MS. Yeah.
4) I hadn't made the link between customer service and security. You're completely right about it needing to be a cultural element.
--Dan
One of the more interesting things I've seen out of this war was the unveiling of some absolutely brutally honest product reviews from the Marines.
Put simply -- this ain't the first clotting agent thats been developed, but oh boy does QuikClot apparently fail. Story here:
http://www.defensetech.org/archives/000458.html
and the PDF (which rocks) is here:
http://www.sftt.org/PDF/article05122003a.pdf
--Dan
Lesse...I was there, Dug Song was there, K2, Shok, and Dino were there...a hacker con it most certainly was, just with a rather different audience than normal.
Yo, Carrot--
You've got a point. Sorry 'bout that.
--Dan
http://blackhat.com/presentations/bh-europe-05/BH_ EU_05-Kaminsky.pdf
It wasn't so much the question, as the unexpected nature of it. I'd just finished talking about very different things -- video over DNS, backtunnelling through dual-hosted name servers, etc -- and it had been about 20 minutes since I'd mentioned that, *if* someone asked, I'd show what was wrong with MD5.
No matter. This guy -- I had no idea who he was at the time -- heard something he needed to precisely understand, and got his answer at his first opportunity.
It's kind of cool that senior management at Microsoft a) showed up at an internal hacker con and b) knew enough to not only understand what I was talking about, but was interested enough to demand more.
Dude. Have you met anyone in senior management? There's a reason so many people relate to the Dilbert PHB.
What would you think if almost all the code on your system was assembled by Microsoft -- even the third party stuff?
Strange. Bad. Awful.
But it's the reality with RPM, or even Apt/Emerge. The Linux distributions really have limited how much stuff the average user installs randomly from the net. But it's a temporary thing...Spyware for Linux isn't worth developing, because there aren't enough non-geek eyeballs to sell.
It's overall a pretty cool article, but the comparison I had made when talking to Ina was that spyware-assaulted Windows vs. the always-perfect nature of a fresh Knoppix CD is a surprisingly tough contest, and that people may be willing to give up their own ability to customize their system in return for the ability to protect the basic functionality of their system.
--Dan
That's the point -- there weren't just network programmers, or compiler writers, or the reps from the security business unit who'd go to Black Hat anyway. People from across the organization showed up.
Chill. I was there. You'd have liked it.
So the last event at Blue Hat was a panel with all the speakers, answering general questions from the moderator and the audience. I ended up relaying Conover's experience regarding 18/20 senior managers knowing about heap overflows -- and, no joke, one of the heads of their Security Business Unit stands up and says, "Ah. So who exactly didn't know about heap overflows?"
A number of large companies end up being managed by professional managers who know nothing about the field they're involved in. MS is many things...definitely not one of those.
--Dan
Forget about deep dives -- this could potentially be _very_ cool for diving approximately five to fifteen feet. Just being able to jaunt around a pool, or explore shallow water coral reefs, without having to maintain scuba gear would be rather cool. I imagine a snorkel that doesn't actually need to reach air.
If it was stable enough, it could even be useful for life preservers.
I've seen all the screens w/ present technology. It's all really, really bad. Don't believe the hype, it's all atrocious.
Only thing non-CRT that I've seen be impressive are aligned polarized projectors. They're beautiful, better even than CRT.
Interesting failure modes. We can resolve them as such:
1) If the phone never loses power, it can be presumed it did not move. So the cached previous location can be restored.
2) If the phone does lose power, and is given a new address -- plugging it in can cause it to ring. Then the person, already at the phone, explicitly knows 911 will work. Nice.
A bigger problem comes from -- just how much accuracy is required? How much do you want to demand people tell you when you plug in the phone?
It'll be pretty simple:
/24 subnet.
/24 subnet, you're asked once again for location information.
/24 subnet, calls to 911 are prefaced with "You are being directed to 911 operations at 'foo'. Press zero if you are not located here."
1) The first time you make an outgoing call, you are asked to enter the zip code or city/state (voice recognition) you're located in. That information is tied to your phone, and your
2) The first time you make an outgoing call on a new
3) If many users have different locations from the same
I'm a packet hacker type, and I know all about IP geolocation databases, but they're the wrong approach. I'm sitting here in Vancouver right now and all my traffic comes from either Santa Clara (where my home network is) or New Jersey (where my company network links live). If you want to know which 911 to give me -- *ask*.
That the result will be a very accurate geolocation database is just gravy.
Note, I'm not saying this is how things _might_ be solved. I can imagine geolocation as a last ditch bonus just in case. But short of putting a cell transponder w/ GPS in every VoIP device -- something we can't even get in cells -- utterly silent 911 tracing ain't happening.
--Dan
AC--
In case you see this:
A problem with the engine can take down the plane.
FAA policy is that plane crashes are very, very bad. Absurd amounts of procedures are created to prevent plane crashes. Liability for plane crashes can be massive.
The engine manufacturer can't rule out that third party tools would find different problems than their own; the whole point of you owning this third party device is that, as a pilot, you've made a judgement call that the manufacturer's supplies were insufficient. Your call is being overridden by an overprotective manufacturer, treating you as an enemy to be obfuscated against.
If you crash -- it cannot be ruled out that you might not have if you had this extra information. All the FAA needs to say is -- those who interfere with pilot judgement may face consequences for such decisions -- and the potential liability will outweigh anything else.
--Dan
It's simple, really.
"Can you say, with absolute certainty, that no third party fault detector would have found the problem with your engine?"
"No, but..."
"So, you intentionally embarked on a development program that hid problems with your engines. Thank you."
This exchange, vaguely hinted at by FAA, would be quite enough.
No, it does not make complete sense. It does if you are a freenode-using, FSF-supporting GPL Zealot, but under any other condition it does not make since (i.e. the real world.).
*shrugs* I don't understand why people think the GPL is so onerous. Have you seen the tripe that gets put into EULAs? The GPL specifically says you can do whatever you want with this code, including merge it into your own projects and share nothing of them. It's only when you merge _and_ distribute that its requirements pop up, and if you don't like them -- well, negotiate something better.
You don't link syscalls. Syscalls are re-enterant entrypoints into kernel namespace, and their shims (AND _syscall()) are provided by glibc, NOT the kernel.
You need to use glibc to use the kernel? All those people with dietlibc will be very surprised to hear. The kernel has a set of numerically identified interfaces, each of which is triggered by interrupt. There are any number of ways of feeding these interfaces, but make no mistake -- it's kernel, not libc.
As for modules -- we're saying the same thing.
*shrugs* No, it makes complete sense. Copyrights control distribution, not use. If the use of a piece of code is to output some content, push something on screen, or whatever else, then anything can drive it -- open source, closed source, or whatever. It's only when you distribute code that insinuates itself at the source level that you need to share the code you added.
The Linux exception comes from the fact that you directly link chunks of Linux into your own modules when you create kernel modules. You are correct that it's ludicrous to consider the generic kernel syscall interface living under the same exemption.
--Dan
To be clear -- using dshow filters, piped executables, and so on is fine by GPL; you're just not allowed to link the code into your application. It looks like they modified the GUI tools, though, without releasing source. That's not allowed.
Yeah, and how's the 3D support of these RTOS's? :)
The problem is that we have entire architectural pipelines -- too complex for a simple DSP -- that don't generally support the level of very high speed reactions and changes that reality itself exhibits in response to our actions. Linux, with the new pre-emptible kernel code developed for low latency audio, does show some very nice potential (sub-ms scheduling is good). But fitting the position/draw loop into what's necessary is still a challenge.
AC--
The images in front of your eye need to be in motion _while_ you're moving your head. You're right, they don't necessarily need to be blurred, but saccade will be suppressed if you've got this stable picture in front of you when there's supposed to be a blur initiating.
I've experienced this on HMD's. Takes a bit to recognize what's wrong.
What's wrong with VR? Hmm, this was the first tech subject I ever investigated in depth, and it's kind of amusing it hasn't gotten much better after all these years. I was just ranting about this a little while ago, but I'll go more in depth here:
There are some real problems with latency. Modern operating systems have a really hard time with the idea that there are hard deadlines that must be met on a sub-100ms basis. Even some graphics programmers hold onto the myth that 30fps has anything to do with how fast the human eye can detect motion. The reality is that we detect different faults at different rates, but anything that's tied to our own sense of motion has to be accurate at somewhere around the frame rate of touch.
The frame rate of our haptic senses is something on the order of 3000 frames per second.
That doesn't mean you need to update a display at 3000fps (though ironically enough, that's approximately the frequency of the fluorescent backplane on an LCD), but it does mean that if you're trying to show someone something at the same time a touch simulator is telling them they are, frames need to interrupt-updated at a speed that even the core operating system has trouble handling.
What do I mean by touch simulators? Nothing so complex as this per-finger force feedback weirdness that pulled back on each finger as I touched a virtual cockpit back at SIGGRAPH. No, anything involving a head-mounted display and a position detector is a touch simulator; the "feel" comes from within your head and neck and the reaction is to be visually accompanied by a display of motion.
But the display is always, always, always late! Look at the monitor. Now move your head and eyes, look at whatever's 90 degrees off to the right. For a noticable sub-second interval, you went blind, so that your brain would not need to contend with this blurry streaky mess. To be immersive, VR systems need to detect your motion, synthesize the appropriate blur-frames, and (hardest of all) have a convenient stable frame in front of you as you're escaping motion-blindness.
Everything head-mounted fails this just brutally.
There are vague successes in VR, of course. Driving simulations work fantastically, but it's not like driving is a massively natural feat for our brains to have adapted to in the first place. Screens on every window clean up the above quite neatly. And the phobia work functions because the fears operate on such a low level that your brain isn't able to employ resources such as "heh, that spider's moving wrong". These are useful and impressive successes, but in terms of general purpose "you are elsewhere" mechanisms -- until latency is dealt with appropriately, this will continue to be broken tech.
--Dan
Funny to see this code; I was just pinging the developers of C Global Surveyor (a vaguely similar tool that operates on C/C++ code instead of Java) to see if I could get access to their work. I didn't get a reply, but hopefully Java Pathfinder will give them the cover they need...seriously, CGS looks absolutely brilliant.
Oh, high latency issues have been studied for years (see the TCP Performance Enhancing Proxies, like SkyX). There's precious little in the open source world that implements such things, though, and it's needed.
Too bad there's no code for this Linklider out there...it looks quite cool. Thanks!
--Dan
I looked at DTN earlier today; they've got some good ideas and I want to play with their code. But they seem much more tied into ad-hoc/disconnected operation than anything to do with extreme-high-latency (but large pipe) links. Plus I couldn't find anything that dealt with rate adaptivity, which is a wildly difficult problem without rapid feedback.
:) It'll hopefully inform my own work with Fragile Router Protocol (my system that gets ~65K/sec out of DNS).
I *am* happy to see some code, don't get me wrong
--Dan