Onderwerp: Re: [VulnWatch] Details of Sybase ASE bugs withheld

Hey all,

am I understanding this correctly ? Sybase is threatening "something"
so that the technical details of the vulnerability are kept secret
indefinitely ?

This is a rather curious development. Are the pre/post patch versions
freely downloadable ?

Cheers,
Halvar

--
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl

Hey Halvar,
> am I understanding this correctly ? Sybase is threatening "something"
> so that the technical details of the vulnerability are kept secret
> indefinitely ?

Yes - you understand correctly. Needless to say I hope all of this can be
resolved amicably; and the details will be published.

>
> This is a rather curious development. Are the pre/post patch versions
> freely downloadable ?

To be honest, I don't know, but if the patch is freely downloadable, let's
face it, the "details" are there to anyone with a disassembler, anyway. This
kind of legal threat achieves nothing other than to make legit researchers
fearful about being sued if they find and publish security issues - even if
they do so in a responsible manner. In such a climate security research will
be driven underground - which is where the "good guys" really don't want it
to be.


Cheers,
David Litchfield
Research Scientist
NGSSoftware Ltd
http://www.ngssoftware.com/

On Mon, 21 Mar 2005 21:50:22 -0000
"David Litchfield" <davidl@ngssoftware.com> wrote:

> Hey Halvar,
> > am I understanding this correctly ? Sybase is threatening "something"
> > so that the technical details of the vulnerability are kept secret
> > indefinitely ?
>
> Yes - you understand correctly. Needless to say I hope all of this can be
> resolved amicably; and the details will be published.
>
> >
> > This is a rather curious development. Are the pre/post patch versions
> > freely downloadable ?
>
> To be honest, I don't know, but if the patch is freely downloadable, let's
> face it, the "details" are there to anyone with a disassembler, anyway. This
> kind of legal threat achieves nothing other than to make legit researchers
> fearful about being sued if they find and publish security issues - even if
> they do so in a responsible manner. In such a climate security research will
> be driven underground - which is where the "good guys" really don't want it
> to be.
>
>
> Cheers,
> David Litchfield
> Research Scientist
> NGSSoftware Ltd
> http://www.ngssoftware.com/
>
>

Pardon my ignorance, but on what legal grounds can they do anything if you tell
them f' off and release anyway? This is absolute insanity. Who do they think
they are? They don't own your intellectual property. I'd call their bluff if I
were you, but then again I'm not

--
[ sean ]

If the bug was found by disassembling Sybase's code then Sybase probably =
does have a legal position to do this. I haven't read Sybase's EULA but =
most have a provision prohibiting reverse engineering of code.


-----Original Message-----
=46rom: sean [mailto:infamous41md@hotpop.com]
Sent: Mon 3/21/2005 5:54 PM
To: bugtraq@securityfocus.com
Cc:=09
Subject: Re: [VulnWatch] Details of Sybase ASE bugs withheld

On Mon, 21 Mar 2005 21:50:22 -0000
"David Litchfield" <davidl@ngssoftware.com> wrote:


Pardon my ignorance, but on what legal grounds can they do anything if you =
tell
them f' off and release anyway=3F This is absolute insanity. Who do they =
think
they are=3F They don't own your intellectual property. I'd call their =
bluff if I
were you, but then again I'm not

--=20
[ sean ]







Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate =
companies are not responsible for errors or omissions in this e-mail =
message. Any personal comments made in this e-mail do not reflect the views=
=
of Blue Cross Blue Shield of Florida, Inc. The information contained in =
this document may be confidential and intended solely for the use of the =
individual or entity to whom it is addressed. This document may contain =
material that is privileged or protected from disclosure under applicable =
law. If you are not the intended recipient or the individual responsible =
=66or delivering to the intended recipient, please (1) be advised that any =
use, dissemination, forwarding, or copying of this document IS STRICTLY =
PROHIBITED; and (2) notify sender immediately by telephone and destroy the =
document. THANK YOU.

Another question, how can one prove that it was found by disassembling the code?
What if it were found by brute force testing? I can't imagine that a company
would prohibit the user from testing the functionality of a product they sell? A
friend of mine told me this sort of legal piracy was commonplace - have there
ever been any actual legal proceedings in a similar situation? I'm not finding
anything good on google.


On Tue, 22 Mar 2005 12:12:19 -0500
"Marchand, Tom" <Tom.Marchand@bcbsfl.com> wrote:

> If the bug was found by disassembling Sybase's code then Sybase probably does
> have a legal position to do this. I haven't read Sybase's EULA but most have
> a provision prohibiting reverse engineering of code.
>
>
> -----Original Message-----
> From: sean [mailto:infamous41md@hotpop.com]
> Sent: Mon 3/21/2005 5:54 PM
> To: bugtraq@securityfocus.com
> Cc:
> Subject: Re: [VulnWatch] Details of Sybase ASE bugs withheld
>
> On Mon, 21 Mar 2005 21:50:22 -0000
> "David Litchfield" <davidl@ngssoftware.com> wrote:
>
>
> Pardon my ignorance, but on what legal grounds can they do anything if you
> tell them f' off and release anyway? This is absolute insanity. Who do they
> think they are? They don't own your intellectual property. I'd call their
> bluff if I were you, but then again I'm not
>
> --
> [ sean ]
>
>
>
>
>
>
>
> Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate
> companies are not responsible for errors or omissions in this e-mail message.
> Any personal comments made in this e-mail do not reflect the views of Blue
> Cross Blue Shield of Florida, Inc. The information contained in this document
> may be confidential and intended solely for the use of the individual or
> entity to whom it is addressed. This document may contain material that is
> privileged or protected from disclosure under applicable law. If you are not
> the intended recipient or the individual responsible for delivering to the
> intended recipient, please (1) be advised that any use, dissemination,
> forwarding, or copying of this document IS STRICTLY PROHIBITED; and (2) notify
> sender immediately by telephone and destroy the document. THANK YOU.
>
>


--
[ sean ]

On Tue, 22 Mar 2005, Marchand, Tom wrote:

> If the bug was found by disassembling Sybase's code then Sybase probably
> does have a legal position to do this. I haven't read Sybase's EULA but
> most have a provision prohibiting reverse engineering of code.

It is certainly possible to discover security flaws without reverse
engineering. You don't need to get to the point where you know how the
internals of a program are built. Injecting crafted data into a program's
inputs and observing whether or not it crashes or misbehaves is simply
using the program.

If it is decided by the courts that all security analysis is covered by a
blanket EULA no reverse engineering provision, a potential solution for
security researchers is to require that the vendor indemnify them from
reverse engineering civil suits before disclosing information them.

-Chris

And what happens when the vendor won't indemnify the researchers=3F No =
more security bulletins=3F Wouldn't the vendors love that. Or would =
security researchers become outlaws=3F


-----Original Message-----
=46rom: Chris Wysopal [mailto:weld@vulnwatch.org]
Sent: Tue 3/22/2005 4:26 PM
To: Marchand, Tom
Cc: bugtraq@securityfocus.com
Subject: RE: [VulnWatch] Details of Sybase ASE bugs withheld



On Tue, 22 Mar 2005, Marchand, Tom wrote:

> If the bug was found by disassembling Sybase's code then Sybase probably
> does have a legal position to do this. I haven't read Sybase's EULA but
> most have a provision prohibiting reverse engineering of code.

It is certainly possible to discover security flaws without reverse
engineering. You don't need to get to the point where you know how the
internals of a program are built. Injecting crafted data into a program's
inputs and observing whether or not it crashes or misbehaves is simply
using the program.

If it is decided by the courts that all security analysis is covered by a
blanket EULA no reverse engineering provision, a potential solution for
security researchers is to require that the vendor indemnify them from
reverse engineering civil suits before disclosing information them.

-Chris






Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate =
companies are not responsible for errors or omissions in this e-mail =
message. Any personal comments made in this e-mail do not reflect the views=
=
of Blue Cross Blue Shield of Florida, Inc. The information contained in =
this document may be confidential and intended solely for the use of the =
individual or entity to whom it is addressed. This document may contain =
material that is privileged or protected from disclosure under applicable =
law. If you are not the intended recipient or the individual responsible =
=66or delivering to the intended recipient, please (1) be advised that any =
use, dissemination, forwarding, or copying of this document IS STRICTLY =
PROHIBITED; and (2) notify sender immediately by telephone and destroy the =
document. THANK YOU.

--nextPart1579123.fqGQ0O7qjC
Content-Type: text/plain;
charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 22 March 2005 14:53, Marchand, Tom wrote:
> And what happens when the vendor won't indemnify the researchers? No mo=
re
> security bulletins? Wouldn't the vendors love that. Or would security
> researchers become outlaws?

It gets worse if you consider that the researcher may be researching a COTS=
=20
product on behalf of a client who wants the software evaluated before it is=
=20
implemented/purchased. Now where does the EULA lie? Company X bought the=20
software, but pays me to evaluate it in a cubicle on Company X's property.=
=20
Does the EULA apply to me? What if Company X already installed it on a=20
computer, and *they* clicked "I Agree" during the license question and I am=
=20
just there to rip things apart bit by bit?

This is why EULAs don't work in this context.

Additionally, myself and/or NMRC has been threatened with legal action from=
=20
several companies or have done "legalish" things to try to scare us ("pleas=
e=20
GPG sign NMRC's disclosure policy with *your personal* GPG key and email it=
=20
to us before releasing your advisory we don't want published"). My experien=
ce=20
through my employer BindView also leads me to believe that given the chance=
=20
any and all vendors will do anything to prevent public disclosure of bugs.

<tinfoilhat>
IMO, several large vendors are waiting for one of the smaller companies to=
=20
risk the bad publicity of going after a security researcher (criminal, civi=
l,=20
or both) so a precedence has been set. Assuming the courts decide in favor =
of=20
the company instead of the researcher, security research as we know it will=
=20
end as all the vendors come after us like biblical locust swarms, and we wi=
ll=20
go back underground, old school style.
</tinfoilhat>

=2D-=20
# Simple Nomad -- thegnome@nmrc.org #
# C1B1 E749 25DF 867C 36D4 1E14 247A A4BD 6838 F11D #
# http://www.nmrc.org/~thegnome/ #

--nextPart1579123.fqGQ0O7qjC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBCQYVCJHqkvWg48R0RAnd/AKCIyqu8qB8LA+AS4U+p2w7RV0lZBACgwntN
HXoHMEvH3zvTrl7/e1lFWLw=
=d1S7
-----END PGP SIGNATURE-----

--nextPart1579123.fqGQ0O7qjC--

What constitutes the 'technical details'. Have the little lawyer spell
that out in black and white, then work around it. Once that person who
practices law commits to their defintion, give us the indvidual's name so
that we can both chuckle and avoid 'renting' them in the future.

--
http://www.malware.com

--v9Ux+11Zm5mwPlX6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005-03-22 15:38:51 -0500, sean wrote:
> Another question, how can one prove that it was found by disassembling th=
e code?

In the EU, reverse engineering is explicitely allowed if it is done to
ensure interoperability. (Is an exploit an interoperable program? :-))

> What if it were found by brute force testing? I can't imagine that a com=
pany
> would prohibit the user from testing the functionality of a product they =
sell?

Oracle prohibits their users from publishing performance benchmarks.
(Not from doing benchmarks, mind you, just from publishing the results)

> A friend of mine told me this sort of legal piracy was commonplace -
> have there ever been any actual legal proceedings in a similar
> situation?

It is generally believed (at least here in Europe) that quite a lot of
the clauses in a typical licence are against the law and couldn't be
upheld before court. Companies probably hope that their customers will
comply anyway, either because they don't know their rights or because
they cannot afford a lengthy law suit (even if they have good chances of
winning).

hp

--=20
_ | Peter J. Holzer \Beta means "we're down to fixing misspelled commen=
ts in
|_|_) | Sysadmin WSR \the source, and you might run into a memory leak =
if=20
| | | hjp@wsr.ac.at \you enable embedded haskell as a loadable module=
and
__/ | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae@o=
p5.se

--v9Ux+11Zm5mwPlX6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQDQAwUBQkEwSFLjemazOuKpAQEZKQXTB7n9RTjU0Yly3Q7cFD xKDODh22mkgy6y
K/xa+qT/EK9RFT92eOYMXMH1GZr2UxvGn0eOl4EczuId9uC1Mw9UHZMeen DSMMrv
+7uVkDcZJVfBxuefrYXtGv70FO5yZl58xRds2pkVME8gweZ2QI vCn55EPuCGr/b+
h7yfo4zEzy76Nyogi06sJ5Jywwz/UKdKjzcvnOQnIpBfbg/wnuIXqnn/R10Tcwrh
HIxQolwSZLRVY0Za9cJ+4u4y0w==
=dzBg
-----END PGP SIGNATURE-----

--v9Ux+11Zm5mwPlX6--

I think Simple Nomad wrote an excellent analysis of the problem of a COTS
vendor (in this case, Sybase) "requesting" (make legal threats) against a
security research firm to not disclose the details of a discovered
vulnerability.

<IMHONSFME - In My Humble Opinion Not Speaking For My Employer mode on>

Looking at this from my point of view as an employee of a Fortune 200
company with a massively complex IT infrastructure, in the microcosm of
this specific Sybase vulnerability, it is a two edged sword: one edge may
be good for us in that only the more dedicated of crackers will find and
build an exploit for the vulnerability in the absence of the full details;
the other edge is that we still do not know the precise details and so we
are less certain what and how much to do to protect ourselves against it.

It would be foolish to assume that an effective exploit for the
vulnerability will not be created and published (or for that matter than
an effective exploit for the vulnerability is not already quietly
circulating). Therefore, on the whole, even in the microcosm of our large
company and this one specific incident, I do not think that it is good for
us that a commercial software product vendor has been able to even
temporarily silence a security research firm.

In the broader context, I believe that Simple Nomad is exactly right: it
will be bad for us and for everyone who uses such commercial products if
security research firms are effectively gagged by legal threats, because
we will less and less know what vulnerabilities exist in the products we
use, until such time as we suffer an actual exploit against them.

To that end, I have encouraged my employer to perform some commercial
activism by contacting the commercial product vendor, as a concerned
customer, and suggesting that we disapprove of their policy of using legal
threats to keep the vulnerability details quiet. I have further suggested
that we should copy such notice to our lobbyists / elected
representatives.

</IMHONSFME - In My Humble Opinion Not Speaking For My Employer mode off>

-Jay Libove, CISSP





On Wed, 23 Mar 2005, Simple Nomad wrote:
> On Tuesday 22 March 2005 14:53, Marchand, Tom wrote:
>> And what happens when the vendor won't indemnify the researchers? No more
>> security bulletins? Wouldn't the vendors love that. Or would security
>> researchers become outlaws?
>
> It gets worse if you consider that the researcher may be researching a COTS
> product on behalf of a client who wants the software evaluated before it is
> implemented/purchased. Now where does the EULA lie? Company X bought the
> software, but pays me to evaluate it in a cubicle on Company X's property.
> Does the EULA apply to me? What if Company X already installed it on a
> computer, and *they* clicked "I Agree" during the license question and I am
> just there to rip things apart bit by bit?
>
> This is why EULAs don't work in this context.
>
> Additionally, myself and/or NMRC has been threatened with legal action from
> several companies or have done "legalish" things to try to scare us ("please
> GPG sign NMRC's disclosure policy with *your personal* GPG key and email it
> to us before releasing your advisory we don't want published"). My experience
> through my employer BindView also leads me to believe that given the chance
> any and all vendors will do anything to prevent public disclosure of bugs.
>
> <tinfoilhat>
> IMO, several large vendors are waiting for one of the smaller companies to
> risk the bad publicity of going after a security researcher (criminal, civil,
> or both) so a precedence has been set. Assuming the courts decide in favor of
> the company instead of the researcher, security research as we know it will
> end as all the vendors come after us like biblical locust swarms, and we will
> go back underground, old school style.
> </tinfoilhat>
>
> --
> # Simple Nomad -- thegnome@nmrc.org #
> # C1B1 E749 25DF 867C 36D4 1E14 247A A4BD 6838 F11D #
> # http://www.nmrc.org/~thegnome/ #
>

>-----Original Message-----
>From: Jay Libove [mailto:libove@felines.org]=20

>I think Simple Nomad wrote an excellent analysis of the problem of a =
COTS=20
>vendor (in this case, Sybase) "requesting" (make legal threats) against =
a=20
>security research firm to not disclose the details of a discovered =
vulnerability.

I second your conclusion to Simple Nomad's analysis. I unfortunately =
have
had and continue to have the same experience with vendors. Some that are
vendors of security products and I honestly expected to be positive. =
</na=EFve>

>To that end, I have encouraged my employer to perform some commercial=20
>activism by contacting the commercial product vendor, as a concerned=20
>customer, and suggesting that we disapprove of their policy of using =
legal=20
>threats to keep the vulnerability details quiet. I have further =
suggested=20
>that we should copy such notice to our lobbyists / elected =
representatives.

Excellent. If everyone on these lists that is a licensed/paying user of =
Sybase
products contacted Sybase to express their concern and displeasure, =
their
stance would quickly change. Let them know you'll vote with your =
dollars.

Anyone remember when someone published Carly the HP CEO's email address
to a certain list and the 1,000's of emails she got over the Snosoft =
lawsuit?
(I think it was Snosoft, wasn't it?)

HP changed their tune really fast and claimed "it was all a =
misunderstanding".

How about a little noise from the community. NGS should drop a name or =
an
email address if they find they cannot make progress on this.

Also, where are the clueless media articles about this? Where are the =
media
folks for that matter? I know you guys are reading BT.

Stop writing about Microsoft-funded studies analyzing Linux security
and write about some real information.

Arian Evans
Sr. Security Engineer
FishNet Security

Phone: 816.421.6611
Toll Free: 888.732.9406
Fax: 816.421.6677

http://www.fishnetsecurity.com



The information transmitted in this e-mail is intended only for the =
addressee and may contain confidential and/or privileged material.=20
Any interception, review, retransmission, dissemination, or other use =
of, or taking of any action upon this information by persons or entities
other than the intended recipient is prohibited by law and may subject =
them to criminal or civil liability. If you received this communication=20
in error, please contact us immediately at 816.421.6611, and delete the =
communication from any computer or network system.