Community Discussions and Support
CVE-2017-9046 - "ssgp.dll" ?

[quote user="cogx"]

http://www.securityfocus.com/archive/1/540601

"v4.72 build 572
Vendor supposedly fixed: January 21, 2016

May 19, 2017 : Public Disclosure"

So,  that post says the flaw is still working in 4.72 build 572, but it was supposed to have been fixed in January 21, 2016 which should mean it was fixed in 4.72 build 572 (Feb 19, 2016)?

[/quote]

I think it's just a typo - the actual bug was fixed in January, in both Mercury and Pegasus Mail. I haven't as yet done a release because, frankly, this is a very minor security issue.

What the vulnerability entails is a common issue where an application allows Windows to search along the path for DLLs when loading them. In theory, this means that someone could place a DLL in a directory in the path earlier than the real version, and Windows would load the bogus one when the load call was made. In practice, this is really hardly an issue: Mercury is typically used as a service, so it's nearly impossible to inject a bogus DLL into the path before it starts up, and while it could possibly be exploited in Pegasus Mail, it's hard to see what benefit it would provide.

In both cases, the solution was easy (it's actually a problem in the TER editor I use, not in Pegasus Mail itself), and I'll have maintenance releases out shortly that address it.

Cheers!

-- David --

<p>[quote user="cogx"]</p><p>http://www.securityfocus.com/archive/1/540601</p><p>"v4.72 build 572 Vendor supposedly fixed: January 21, 2016 May 19, 2017 : Public Disclosure"</p><p>So,  that post says the flaw is still working in 4.72 build 572, but it was supposed to have been fixed in January 21, 2016 which should mean it was fixed in 4.72 build 572 (Feb 19, 2016)?</p>[/quote] I think it's just a typo - the actual bug was fixed in January, in both Mercury and Pegasus Mail. I haven't as yet done a release because, frankly, this is a very minor security issue. What the vulnerability entails is a common issue where an application allows Windows to search along the path for DLLs when loading them. In theory, this means that someone could place a DLL in a directory in the path earlier than the real version, and Windows would load the bogus one when the load call was made. In practice, this is really hardly an issue: Mercury is typically used as a service, so it's nearly impossible to inject a bogus DLL into the path before it starts up, and while it could possibly be exploited in Pegasus Mail, it's hard to see what benefit it would provide. In both cases, the solution was easy (it's actually a problem in the TER editor I use, not in Pegasus Mail itself), and I'll have maintenance releases out shortly that address it. Cheers! -- David --

Just saw this today:

http://www.securityfocus.com/archive/1/540601

"v4.72 build 572
Vendor supposedly fixed: January 21, 2016

May 19, 2017 : Public Disclosure
"

So,  that post says the flaw is still working in 4.72 build 572, but it was supposed to have been fixed in January 21, 2016 which should mean it was fixed in 4.72 build 572 (Feb 19, 2016)?

 

(Long time user, since the DOS version in 1995.)

 

 

<p>Just saw this today:</p><p>http://www.securityfocus.com/archive/1/540601</p><p>"v4.72 build 572 Vendor supposedly fixed: January 21, 2016 May 19, 2017 : Public Disclosure "</p><p>So,  that post says the flaw is still working in 4.72 build 572, but it was supposed to have been fixed in January 21, 2016 which should mean it was fixed in 4.72 build 572 (Feb 19, 2016)?</p><p> </p><p>(Long time user, since the DOS version in 1995.)</p><p> </p><p> </p>

There's something weird with the supposed timeline:

Disclosure Timeline:

=====================================

Vendor Notification: October 8, 2016

Vendor supposedly fixed: January 21, 2016

May 19, 2017 : Public Disclosure

If David Harris would have been notified in October 2016 how could he possibly have fixed this issue in January 2016?

I've notified him of this post so he'll certainly comment on it himself.

<p>There's something weird with the supposed timeline:</p> <blockquote> <pre>Disclosure Timeline: ===================================== Vendor Notification: October 8, 2016 Vendor supposedly fixed: January 21, 2016 May 19, 2017 : Public Disclosure</pre></blockquote> If David Harris would have been notified in October 2016 how could he possibly have fixed this issue in January 2016? <p>I've notified him of this post so he'll certainly comment on it himself.</p>
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

I assume the notification date was a typo and they meant to type October 8, 2015?  In any case, this is the world we live in now, though, the "CVE of the hour" as I call it.  Definitely makes me regret my degree and career choices back in the early 1990s.

I assume the notification date was a typo and they meant to type October 8, 2015?  In any case, this is the world we live in now, though, the "CVE of the hour" as I call it.  Definitely makes me regret my degree and career choices back in the early 1990s.
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft