CreateMutex calls do not specify an DACL.

benlilaj / gears

Automatically exported from code.google.com/p/gears

0 stars 1 forks source link

CreateMutex calls do not specify an DACL. #21

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

Code review of source shows that you are not creating the Mutexes, so 
you're open to all sorts of DOS attacks. Please review code per Larry 
Osterman's post

http://blogs.msdn.com/larryosterman/archive/2007/05/14/what-s-wrong-with-
this-code-part-20-yet-another-reason-that-named-synchronization-objects-
are-dangerous-the-answers.aspx

Original issue reported on code.google.com by idisposa...@gmail.com on 1 Jun 2007 at 6:03

GoogleCodeExporter commented 9 years ago

M1 to investigate.

Original comment by gears.te...@gmail.com on 27 Jun 2007 at 7:12

Added labels: Milestone-M1
Removed labels: Priority-Medium

GoogleCodeExporter commented 9 years ago

Original comment by gears.te...@gmail.com on 27 Jun 2007 at 7:19

Changed state: Accepted

GoogleCodeExporter commented 9 years ago

Original comment by gears.te...@gmail.com on 2 Jul 2007 at 6:59

Added labels: Milestone-M2
Removed labels: Milestone-M1

GoogleCodeExporter commented 9 years ago

Original comment by gears.te...@gmail.com on 4 Sep 2007 at 11:16

Added labels: Milestone-M3
Removed labels: Milestone-M2

GoogleCodeExporter commented 9 years ago

Original comment by gears.te...@gmail.com on 5 Sep 2007 at 12:10

Added labels: Milestone-M4
Removed labels: Milestone-M3

GoogleCodeExporter commented 9 years ago

Follow the bouncing Miletone!

Original comment by idisposa...@gmail.com on 5 Sep 2007 at 3:00

GoogleCodeExporter commented 9 years ago

One more on it's way. I think Chris had some questions about how much this 
matters to
Gears. Maybe he will chime in.

Original comment by gears.te...@gmail.com on 5 Sep 2007 at 3:35

GoogleCodeExporter commented 9 years ago

Original comment by gears.te...@gmail.com on 5 Sep 2007 at 4:40

Added labels: Version-unscheduled
Removed labels: Milestone-M4

GoogleCodeExporter commented 9 years ago

It matters because any old exploit program can cause ANY Gears application on 
any 
WinSta (including ones for other sessions on a Terminal Server machine) to 
crash or 
corrupt things. That would really be a bad thing if someone was actually hoping 
Gears would handle offline access. Simply put, this is obviously exploitable 
and 
releasing Gears with this easy fix ignored would be irresponsible.

Of course, that's just my opinion.

Original comment by idisposa...@gmail.com on 5 Sep 2007 at 5:59

GoogleCodeExporter commented 9 years ago

Marc, can you post a link to more details about the exploit?  That would help us
understand why this is important.

Original comment by gears.te...@gmail.com on 5 Sep 2007 at 6:45

GoogleCodeExporter commented 9 years ago

Quoting from Larry's post linked above "If the ACL creates is too permissive, 
then 
things get scary.  If the DACL grants full access, it means that a bad guy can 
do 
ANYTHING to your event - they can change it's state, they can set a new DACL on 
it 
(locking your application out), etc.  Weak DACLs are a recipe for denial of 
service 
attacks (or worse - depending on the access rights granted and the 
circumstances, 
they can even enable elevation of privilege attacks)."

Original comment by idisposa...@gmail.com on 5 Sep 2007 at 3:13