

Did the “Man with No Name” Feel Insecure? - DiabloD3
http://googleprojectzero.blogspot.com/2014/10/did-man-with-no-name-feel-insecure.html

======
wfunction
Not really related, but I reported a kernel-level bug to Microsoft over a year
ago. It seems like it could be exploitable (it's easy enough to trigger from
user-mode, but I'm not sure how easy it is to exploit for malicious uses other
than DoS attacks). I received a reply that they would look into it, and that
in the meantime I shouldn't disseminate it. However I'm fairly sure it hasn't
been fixed, and it may never be. Should I make it public? Why or why not?

~~~
acdha
If you've confirmed an exploit, what I normally prefer is to send a followup
message stating that you intend to publish in a month and request a comment.
That gives them time to say “Oops, did we forget to tell you it's not
exploitable?” or “It was quietly fixed two months ago”.

~~~
wfunction
I don't have a confirmed exploit (other than a DoS, but I don't think that's
very interesting). I think it may be exploitable but I haven't looked into the
"how" and don't really intend to. I just know it's a hole.

~~~
acdha
In that case I'd probably vote for just giving them another email. If you're
not certain, it's probably not worth the effort of a full advisory.

~~~
wfunction
Ok thanks

------
barrkel
Unnamed objects are not normally used for sharing. Naming an object is
generally only done so that it can be accessed from other processes. The
Windows idiom is to use a name when sharing, and don't use a name when not
sharing.

I would have named these shared memory objects as a matter of course, knowing
their design and purpose. That unnamed ones don't support a DACL is an
interesting bit of trivia, but not much more than that. It seems more a case
of non-idiomatic code.

(PS: I should be more clear here. Without using DuplicateHandle, you can't
open an unnamed object, because you can't address it. It's secured by the guy
who calls DuplicateHandle being in control of who he hands it off to.)

