bulletin: http://www.microsoft.com/technet/security/Bulletin/MS08-009.mspx
Disclosure Timeline:
07/02/2007 - Vendor Contacted
07/02/2007 - Vendor Acknowledged
01/10/2008 - Vendor confirms vulnerability and plans to fix it.
02/12/2008 - Coordinated disclosure
--------------------------------------------------------
2. Fortinet FortiClient Local Privilege Escalation.
Why don't you just fix it?
The fact, that this field ist not properly sanitised means that u don't check all fields by default.
so it may not be an exploitable software bug, but it is a development error...
-----Ursprngliche Nachricht-----
Von: neothermic@phpbb.com [mailto:neothermic@phpbb.com]
in seventh version of the browser. But as I tested at 29.09.2008, IE7 was
also vulnerable to this attack. And as I tested recently, IE8 is also
vulnerable to this attack.
Also I informed Microsoft at 01.10.2008 about it, but they ignored and
didn't fix it. They didn't fix the hole not in IE6, nor in IE7, nor in IE8.
That time I published about this vulnerability at SecurityVulns
(http://securityvulns.com/Udocument636.html).
DoS:
> By tightening up the protection on the directory the sysadmin can
> mitigate the problem. It is in fact the standard way of doing this.
>
If the application sets wrong permissions on files, it is by definition broken.
Yes, setting more restrictive directory permissions can to some extent mitigate
the problem, but not really fix it. What if that application is used by multiple
users?
The problem raised in the original mail is to some extent artificial, as the
only users able to access /proc/<PID>/fd/ are the user with the same UID, as the
process EUID, and root, and if the process is either setuid or setgid,
/proc/<PID>/fd of that process is accessible only by root. Not to tell about
[snip]
> If the application sets wrong permissions on files, it is by definition broken.
> Yes, setting more restrictive directory permissions can to some extent mitigate
> the problem, but not really fix it. What if that application is used by multiple
> users?
There have been cases and quite a few.
My first thoughts were about Word Perfect. Actually it is just a
-------------------------
February 20, 2012: Vulnerability discovered
March 07, 2012: Reported to the vendor, through bugzilla.
March 13, 2012: No vendor respon.
March 21, 2012: Reported again to vendor.
March 27, 2012: Vendor response, studying the best way to fix it,
but they recommend not to setuid by default.
March 31, 2012: The patch was aplied to 5.4 release
11. LEGAL NOTICES
release but asking to have a closer look into it.
2009/06/11 Apple response two PoC's are not working on the latest
release, so Apple don't see the need for any further
action. With regards to n.runs-SA-2009.004, Apple
acknowledge the issue still affects Safari 4 and is
looking to fix it.
2009/06/15 n.runs informs Apple to release this advisory
due to time difference
2009/06/23 n.runs releases this advisory
_______________________________________________________________________
. 2009-11-12:
Core Security Technologies replies that it has re-scheduled publication
to the second Tuesday of December 2009 (December 8) and may discuss
further postponements once MSRC provides more details about the bug and
the plan to fix it. Core notes that it provided only one possible
exploitation scenario and did not investigate others because it seemed
that a single example was sufficient to explain the implied risks.
. 2009-11-12:
MSRC acknowledges receipt of previous mail.
release but asking to have a closer look into it.
2009/06/11 Apple response two PoC's are not working on the latest
release, so Apple don't see the need for any further
action. With regards to n.runs-SA-2009.004, Apple
acknowledge the issue still affects Safari 4 and is
looking to fix it.
2009/06/15 n.runs informs Apple to release this advisory
due to time difference
2009/06/23 n.runs releases this advisory
_______________________________________________________________________
. 2011-05-13:
Technical details sent to Service Desk team.
. 2011-05-16:
The Service Desk team notifies they are analyzing the [CVE-2011-1509]
issue and it will take them some time to fix it. The issue
[CVE-2011-1510] was identified and it will be fixed in SDP 8012, which
is expected by the end of May 2011.
. 2011-05-23:
Core requests to clarify whether the problems will be released
