Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Security Vulnerability Alert - February 26, 2010

0 views
Skip to first unread message

Pamela Fowler

unread,
Feb 26, 2010, 6:11:09 PM2/26/10
to
Dear Valued Ingres Customer:

Information security is of utmost priority to Ingres. A new
vulnerability has recently been identified in Ingres 9.1, Ingres 9.2,
and Ingres 9.3. We have given this vulnerability a security threat
level of ‘Medium’ and recommend that the available security patches be
applied as soon as possible.

Fixes are available for the current release of Ingres 9.1, 9.2, and
9.3 versions on their respective platforms. The security fixes can
be quickly applied with little to no anticipated impact to systems.

Ingres customers with a current support subscription should contact
Ingres Technical Support to obtain the latest patch.

We would like to additionally thank Intevydis Blog for bringing the
following vulnerability to our attention.

Ingres remote user attack after SIGSEGV – bug 123208.
Description: A remote user can send specific data to the DBMS which
triggers a SIGSEGV in memcpy() allowing a remote user to initiate a
Denial of Service (DoS) attack.

For more information about Ingres security alerts and to register to
proactively receive these alerts via email please register at:
http://www.ingres.com/support/security-announcements.php.

Regards,


Bill Maimone Pamela Fowler
Senior Vice President, Engineering VP of Worldwide Support/Security
Vulnerabilities
Ingres Corporation Ingres Corporation

Ingres Forums

unread,
Mar 10, 2010, 2:15:09 AM3/10/10
to

I checked the latest patch for 9.2 which is 13711. It makes no mention
of a fix for this bug.

Is a security fix different from a normal patch ?

The knowledge document says that this problem has been resolved in the
current 9.2 codelines. What does that mean ?

If a remote user can send the data and cause the crash, does that mean
that an internal user can do it as well ?


--
adilia....@nrm.qld.gov.au
------------------------------------------------------------------------
adilia....@nrm.qld.gov.au's Profile: http://community.ingres.com/forum/member.php?userid=3009
View this thread: http://community.ingres.com/forum/showthread.php?t=11706

Ingres Forums

unread,
Mar 10, 2010, 2:43:04 AM3/10/10
to

I can see bug 123208 listed in the patch.html delivered with patch
13711, and the readme on ESD. This bug number is the one referred to in
the Security Vulnerability notice.

Patch 13711 contains the fix you need.


--
denjo02
------------------------------------------------------------------------
denjo02's Profile: http://community.ingres.com/forum/member.php?userid=702

Ingres Forums

unread,
Mar 10, 2010, 7:51:53 PM3/10/10
to

Thanks for your reply. I can see the bug now too. My mistake.

I am still wondering, if a remote user can send the data and cause the
crash, does that mean that an internal user can do it as well ? I might
just raise a call with the service desk to find out.


--
adilia....@nrm.qld.gov.au
------------------------------------------------------------------------
adilia....@nrm.qld.gov.au's Profile: http://community.ingres.com/forum/member.php?userid=3009

Kristoff

unread,
Mar 11, 2010, 3:53:48 AM3/11/10
to
On Mar 11, 1:51 am, Ingres Forums <info-

ing...@kettleriverconsulting.com> wrote:
> Thanks for your reply.  I can see the bug now too.  My mistake.
>
> I am still wondering, if a remote user can send the data and cause the
> crash, does that mean that an internal user can do it as well ? I might
> just raise a call with the service desk to find out.
>
> --
> adilia.murab...@nrm.qld.gov.au
> ------------------------------------------------------------------------
> adilia.murab...@nrm.qld.gov.au's Profile:http://community.ingres.com/forum/member.php?userid=3009

Yes, an internal user can do that too. For remote users there is a
workaround, either use Unix sockets (II_GC_PROT) or use a firewall to
prevent any access to "unusual" ports.(meaning give access to the
needed ports only for ssh, telnet or whatever).
But you can not block the DBMS port for internal users ......

Please note, that this problem exists on Unix/Linux only, no need to
worry when using Windows (relating to this problem of course) or VMS

Kristoff

0 new messages