Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13355 > unrolled thread

Heartbleed bug?

Back to article view | Back to comp.lang.php

Contents

  Heartbleed bug? Kevin Burton <ronald.kevin.burton@gmail.com> - 2014-04-09 05:24 -0700
    Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-09 09:17 -0400
      Re: Heartbleed bug? Robert Heller <heller@deepsoft.com> - 2014-04-09 08:56 -0500
        Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-09 11:21 -0400
          Re: Heartbleed bug? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-09 17:43 +0200
            Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-09 13:37 -0400
              Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-10 08:51 +0200
                Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-10 07:52 -0400
                  Re: Heartbleed bug? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-04-10 14:03 +0200
                    Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-10 12:36 -0400
                    Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 23:01 +0000
                      Re: Heartbleed bug? The Natural Philosopher <tnp@invalid.invalid> - 2014-04-11 00:47 +0100
                        Re: Heartbleed bug? Eli the Bearded <*@eli.users.panix.com> - 2014-04-11 00:38 +0000
                        Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-10 21:58 -0400
                          Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-11 02:59 +0000
                            Re: Heartbleed bug? The Natural Philosopher <tnp@invalid.invalid> - 2014-04-11 04:36 +0100
                            Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-11 12:08 -0400
                  Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-10 22:54 +0200
                    Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 22:45 +0000
                      Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-11 08:33 +0200
                Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 15:47 +0000
          Re: Heartbleed bug? Robert Heller <heller@deepsoft.com> - 2014-04-09 10:56 -0500
            Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-09 13:38 -0400
              Re: Heartbleed bug? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-04-10 00:11 +0200
                Re: Heartbleed bug? Jerry Stuckle <jstucklex@attglobal.net> - 2014-04-10 07:53 -0400
            Re: Heartbleed bug? The Natural Philosopher <tnp@invalid.invalid> - 2014-04-09 21:02 +0100
    Re: Heartbleed bug? Adam Harvey <usenet@adamharvey.name> - 2014-04-09 23:43 +0000
      Re: Heartbleed bug? Eli the Bearded <*@eli.users.panix.com> - 2014-04-10 00:01 +0000
    Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-10 08:43 +0200
      Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-10 08:57 +0200
        Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 15:50 +0000
          Re: Heartbleed bug? The Natural Philosopher <tnp@invalid.invalid> - 2014-04-10 19:37 +0100
          Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-10 22:56 +0200
            Re: Heartbleed bug? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-04-10 23:32 +0200
            Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 23:14 +0000
              Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-11 08:23 +0200
    Re: Heartbleed bug? Denis McMahon <denismfmcmahon@gmail.com> - 2014-04-10 15:42 +0000
      Re: Heartbleed bug? Arno Welzel <usenet@arnowelzel.de> - 2014-04-11 13:00 +0200

Page 1 of 2  [1] 2  Next page →

#13355 — Heartbleed bug?

Anyone know how this bug http://heartbleed.com/ affects PHP when the extension is enabled? Is there a patch for the extension?

[toc] | [next] | [standalone]

#13356

On 4/9/2014 8:24 AM, Kevin Burton wrote:
> Anyone know how this bug http://heartbleed.com/ affects PHP when the extension is enabled? Is there a patch for the extension?
>

You need to be asking the OpenSSL people what products their bug affects.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13357

At Wed, 09 Apr 2014 09:17:46 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote:

> 
> On 4/9/2014 8:24 AM, Kevin Burton wrote:
> > Anyone know how this bug http://heartbleed.com/ affects PHP when the extension is enabled? Is there a patch for the extension?
> >
> 
> You need to be asking the OpenSSL people what products their bug affects.

Since this is a shared library on a typical Linux system (eg LAMP server), it 
will affect any program that links with OpenSSL's library(-ies).  I know that 
at least the CentOS user group is talking about it and I am sure RedHat is 
also looking at it.  (A large number of LAMP servers run CentOS.)

> 

-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                      

[toc] | [prev] | [next] | [standalone]

#13358

On 4/9/2014 9:56 AM, Robert Heller wrote:
> At Wed, 09 Apr 2014 09:17:46 -0400 Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>>
>> On 4/9/2014 8:24 AM, Kevin Burton wrote:
>>> Anyone know how this bug http://heartbleed.com/ affects PHP when the extension is enabled? Is there a patch for the extension?
>>>
>>
>> You need to be asking the OpenSSL people what products their bug affects.
>
> Since this is a shared library on a typical Linux system (eg LAMP server), it
> will affect any program that links with OpenSSL's library(-ies).  I know that
> at least the CentOS user group is talking about it and I am sure RedHat is
> also looking at it.  (A large number of LAMP servers run CentOS.)
>
>>
>

That may or may not be.  It depends on exactly what the problem is - or 
exactly what it affects.  From the description on the website, I can't 
tell.  Can you?

Obviously, though, those who know the code would know exactly what it 
affects.

A bug in a program does not necessarily affect everything that touches 
that program!


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13359

Jerry Stuckle wrote:

> On 4/9/2014 9:56 AM, Robert Heller wrote:
>> At Wed, 09 Apr 2014 09:17:46 -0400 Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>>>
>>> On 4/9/2014 8:24 AM, Kevin Burton wrote:
>>>> Anyone know how this bug http://heartbleed.com/ affects PHP when the
>>>> extension is enabled? Is there a patch for the extension?
>>>>
>>>
>>> You need to be asking the OpenSSL people what products their bug
>>> affects.
>>
>> Since this is a shared library on a typical Linux system (eg LAMP
>> server), it
>> will affect any program that links with OpenSSL's library(-ies).  I
>> know that
>> at least the CentOS user group is talking about it and I am sure
>> RedHat is
>> also looking at it.  (A large number of LAMP servers run CentOS.)
> 
> That may or may not be.  It depends on exactly what the problem is - or
> exactly what it affects.  From the description on the website, I can't
> tell.  Can you?
> 
> Obviously, though, those who know the code would know exactly what it
> affects.
> 
> A bug in a program does not necessarily affect everything that touches
> that program!

ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
2014) just a few hours ago.  (The x64 builds are currently being worked
on.)  So obviously PHP's OpenSSL extension is affected by the
"heartbleed" bug (at least on Windows).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#13361

On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 4/9/2014 9:56 AM, Robert Heller wrote:
>>> At Wed, 09 Apr 2014 09:17:46 -0400 Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>>
>>>> On 4/9/2014 8:24 AM, Kevin Burton wrote:
>>>>> Anyone know how this bug http://heartbleed.com/ affects PHP when the
>>>>> extension is enabled? Is there a patch for the extension?
>>>>>
>>>>
>>>> You need to be asking the OpenSSL people what products their bug
>>>> affects.
>>>
>>> Since this is a shared library on a typical Linux system (eg LAMP
>>> server), it
>>> will affect any program that links with OpenSSL's library(-ies).  I
>>> know that
>>> at least the CentOS user group is talking about it and I am sure
>>> RedHat is
>>> also looking at it.  (A large number of LAMP servers run CentOS.)
>>
>> That may or may not be.  It depends on exactly what the problem is - or
>> exactly what it affects.  From the description on the website, I can't
>> tell.  Can you?
>>
>> Obviously, though, those who know the code would know exactly what it
>> affects.
>>
>> A bug in a program does not necessarily affect everything that touches
>> that program!
>
> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
> 2014) just a few hours ago.  (The x64 builds are currently being worked
> on.)  So obviously PHP's OpenSSL extension is affected by the
> "heartbleed" bug (at least on Windows).
>

Does it?  Or does it mean they just want to keep up with the latest 
release?  And if it does affect PHP, what functions does it affect, and 
how does it affect them?


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13368

Jerry Stuckle, 2014-04-09 19:37:

> On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
[...]
>> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
>> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
>> 2014) just a few hours ago.  (The x64 builds are currently being worked
>> on.)  So obviously PHP's OpenSSL extension is affected by the
>> "heartbleed" bug (at least on Windows).
>>
> 
> Does it?  Or does it mean they just want to keep up with the latest 
> release?  And if it does affect PHP, what functions does it affect, and 
> how does it affect them?

I assume PHP does keep up with the latest release because they *are*
affected by the bug e.g. in stream_socket_enable_crypto().


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#13370

On 4/10/2014 2:51 AM, Arno Welzel wrote:
> Jerry Stuckle, 2014-04-09 19:37:
>
>> On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
> [...]
>>> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
>>> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
>>> 2014) just a few hours ago.  (The x64 builds are currently being worked
>>> on.)  So obviously PHP's OpenSSL extension is affected by the
>>> "heartbleed" bug (at least on Windows).
>>>
>>
>> Does it?  Or does it mean they just want to keep up with the latest
>> release?  And if it does affect PHP, what functions does it affect, and
>> how does it affect them?
>
> I assume PHP does keep up with the latest release because they *are*
> affected by the bug e.g. in stream_socket_enable_crypto().
>
>

You can ASS-U-ME all you want.  I go by the facts.  And if I were 
concerned about PHP being involved, I would ask the OpenSSL people.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13372

Jerry Stuckle wrote:

> On 4/10/2014 2:51 AM, Arno Welzel wrote:
>> Jerry Stuckle, 2014-04-09 19:37:
>>
>>> On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
>> [...]
>>>> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
>>>> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
>>>> 2014) just a few hours ago.  (The x64 builds are currently being worked
>>>> on.)  So obviously PHP's OpenSSL extension is affected by the
>>>> "heartbleed" bug (at least on Windows).
>>>
>>> Does it?  Or does it mean they just want to keep up with the latest
>>> release?  And if it does affect PHP, what functions does it affect, and
>>> how does it affect them?
>>
>> I assume PHP does keep up with the latest release because they *are*
>> affected by the bug e.g. in stream_socket_enable_crypto().
> 
> You can ASS-U-ME all you want.  I go by the facts.  And if I were
> concerned about PHP being involved, I would ask the OpenSSL people.

I would rather ask the PHP people, because they know best in which way
PHP uses OpenSSL.  Fortunately, that is not necessary anymore:

<news:li4lve$l1h$1@dont-email.me>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#13376

On 4/10/2014 8:03 AM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 4/10/2014 2:51 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 2014-04-09 19:37:
>>>
>>>> On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
>>> [...]
>>>>> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
>>>>> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
>>>>> 2014) just a few hours ago.  (The x64 builds are currently being worked
>>>>> on.)  So obviously PHP's OpenSSL extension is affected by the
>>>>> "heartbleed" bug (at least on Windows).
>>>>
>>>> Does it?  Or does it mean they just want to keep up with the latest
>>>> release?  And if it does affect PHP, what functions does it affect, and
>>>> how does it affect them?
>>>
>>> I assume PHP does keep up with the latest release because they *are*
>>> affected by the bug e.g. in stream_socket_enable_crypto().
>>
>> You can ASS-U-ME all you want.  I go by the facts.  And if I were
>> concerned about PHP being involved, I would ask the OpenSSL people.
>
> I would rather as k the PHP people, because they know best in which way
> PHP uses OpenSSL.  Fortunately, that is not necessary anymore:
>
> <news:li4lve$l1h$1@dont-email.me>
>

You can ask PHP people all you want.  But if you want a GOOD answer, ask 
the people who know the code surrounding the bug.

PHP people don't typically know the insides of OpenSSL, and how it 
works.  Therefore they don't know what PHP functions may be involved.

And those who think they do know are only showing how little they really 
know.  But then some people think because they can code PHP they are 
experts in EVERYTHING.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13383

On Thu, 10 Apr 2014 14:03:25 +0200, Christoph Michael Becker wrote:

> Jerry Stuckle wrote:

>> You can ASS-U-ME all you want.  I go by the facts.  And if I were
>> concerned about PHP being involved, I would ask the OpenSSL people.

> I would rather ask the PHP people, because they know best in which way
> PHP uses OpenSSL.  Fortunately, that is not necessary anymore:

As far as I can tell, PHP does not "use" OpenSSL directly itself, unless 
a person writing php scripts calls functions that do use OpenSSL, and it 
only seems to be when those functions are used that the vulnerability can 
be exploited.

For example, the following php script as a web page has no exposure to 
the OpenSSL vulnerability:

<?php
echo "<!doctype html><html lang='en'><head><title>Test</title></
head><body><h1>Hello World</h1></body></html>"
?>

However, if you have perhaps written a server process in php that opens 
sockets for encrypted communication, or perhaps if you have been opening 
https sessions as a client using curl, then you may have exposed the 
vulnerability in such a way that it could be exploited (and I'm not 
actually sure about the curl thing).

Hence, for any specific case, it is only possible to answer the question 
"is this PHP installation exposed to heartbleed" by knowing whether the 
PHP code is exposing the exploitable vulnerability. To know that, you 
need to know enough about the SSL side of the vulnerability to know if 
your PHP calls are calling the affected SSL features, and enough about 
the individual PHP installation you are discussing to know what SSL 
features it calls.

So basically no-one here can judge the vulnerability of the php code on 
any individual server to heartbleed unless they have a pretty intimate 
knowledge of the php code running on that server and know enough about 
the php / ssl interfaces and heartbleed to identify any php calls that 
may expose the vulnerability.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#13385

On 11/04/14 00:01, Denis McMahon wrote:
> On Thu, 10 Apr 2014 14:03:25 +0200, Christoph Michael Becker wrote:
>
>> Jerry Stuckle wrote:
>
>>> You can ASS-U-ME all you want.  I go by the facts.  And if I were
>>> concerned about PHP being involved, I would ask the OpenSSL people.
>
>> I would rather ask the PHP people, because they know best in which way
>> PHP uses OpenSSL.  Fortunately, that is not necessary anymore:
>
> As far as I can tell, PHP does not "use" OpenSSL directly itself, unless
> a person writing php scripts calls functions that do use OpenSSL, and it
> only seems to be when those functions are used that the vulnerability can
> be exploited.
>
> For example, the following php script as a web page has no exposure to
> the OpenSSL vulnerability:
>
> <?php
> echo "<!doctype html><html lang='en'><head><title>Test</title></
> head><body><h1>Hello World</h1></body></html>"
> ?>
ER, it COULD if it was running on a secure server!!!

>
-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#13386

In comp.lang.php, The Natural Philosopher  <tnp@invalid.invalid> wrote:
> On 11/04/14 00:01, Denis McMahon wrote:
> > As far as I can tell, PHP does not "use" OpenSSL directly itself, unless
> > a person writing php scripts calls functions that do use OpenSSL, and it
> > only seems to be when those functions are used that the vulnerability can
> > be exploited.

You can, however, use OpenSSL in PHP without calling any functions that
have "ssl" in the name.

> > For example, the following php script as a web page has no exposure to
> > the OpenSSL vulnerability:
> >
> > <?php
> > echo "<!doctype html><html lang='en'><head><title>Test</title></
> > head><body><h1>Hello World</h1></body></html>"
> > ?>
> ER, it COULD if it was running on a secure server!!!

No, that script would not. Or maybe it will make more sense like this:
"ER, that script WOULD NOT!!!1111"

In your scenario, the server (eg, Apache) has an OpenSSL
vulnerability, not the PHP component. On some of my servers OpenSSL
is being used by PHP because I am using the curl module to interact
with an SSL server. I suspect PHP can use OpenSSL for
fopen("https://...") type constructs, too. I'm not sure I've ever
tried fopen() with https.

From "grep -i ssl configure", it looks like OpenSSL is the only SSL
library that PHP (4.4.x, 5.4.x) will attempt to use. Apparently is/can
be used by the Kerberos and imap functions, too. 

From "grep -i ssl configure", Apache (2.2.x) can use OpenSSL or RSA SSL-C.

Elijah
------
or you could terminate ssl on the load balancer and not in the server at all

[toc] | [prev] | [next] | [standalone]

#13387

On 4/10/2014 7:47 PM, The Natural Philosopher wrote:
> On 11/04/14 00:01, Denis McMahon wrote:
>> On Thu, 10 Apr 2014 14:03:25 +0200, Christoph Michael Becker wrote:
>>
>>> Jerry Stuckle wrote:
>>
>>>> You can ASS-U-ME all you want.  I go by the facts.  And if I were
>>>> concerned about PHP being involved, I would ask the OpenSSL people.
>>
>>> I would rather ask the PHP people, because they know best in which way
>>> PHP uses OpenSSL.  Fortunately, that is not necessary anymore:
>>
>> As far as I can tell, PHP does not "use" OpenSSL directly itself, unless
>> a person writing php scripts calls functions that do use OpenSSL, and it
>> only seems to be when those functions are used that the vulnerability can
>> be exploited.
>>
>> For example, the following php script as a web page has no exposure to
>> the OpenSSL vulnerability:
>>
>> <?php
>> echo "<!doctype html><html lang='en'><head><title>Test</title></
>> head><body><h1>Hello World</h1></body></html>"
>> ?>
> ER, it COULD if it was running on a secure server!!!
>
>>

But that wouldn't be a PHP problem.  It would be an Apache problem.


-- 

Ineptocracy

(in-ep-toc’-ra-cy). 1. Anything involving TNP.  2. See 1.
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13388

On Thu, 10 Apr 2014 21:58:01 -0400, Jerry Stuckle wrote:

> On 4/10/2014 7:47 PM, The Natural Philosopher wrote:
>> On 11/04/14 00:01, Denis McMahon wrote:

>>> For example, the following php script as a web page has no exposure to
>>> the OpenSSL vulnerability:

>>> <?php echo "<!doctype html><html lang='en'><head><title>Test</title></
>>> head><body><h1>Hello World</h1></body></html>"
>>> ?>

>> ER, it COULD if it was running on a secure server!!!

> But that wouldn't be a PHP problem.  It would be an Apache problem.

You expect him to comprehend the distinction following years of evidence 
to the contrary?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#13389

On 11/04/14 03:59, Denis McMahon wrote:
> On Thu, 10 Apr 2014 21:58:01 -0400, Jerry Stuckle wrote:
>
>> On 4/10/2014 7:47 PM, The Natural Philosopher wrote:
>>> On 11/04/14 00:01, Denis McMahon wrote:
>
>>>> For example, the following php script as a web page has no exposure to
>>>> the OpenSSL vulnerability:
>
>>>> <?php echo "<!doctype html><html lang='en'><head><title>Test</title></
>>>> head><body><h1>Hello World</h1></body></html>"
>>>> ?>
>
>>> ER, it COULD if it was running on a secure server!!!
>
>> But that wouldn't be a PHP problem.  It would be an Apache problem.
>
> You expect him to comprehend the distinction following years of evidence
> to the contrary?
>
Read what the poster said.

He said 'the following php script as a web page has no exposure to
the OpenSSL vulnerability'

He didn't say a PHP vulnerabilty.

Or specify a PHP problem.

If you interpret that the way its written it means 'you wont have a 
problem with this PHP script'

I pointed out that in fact you could.

The fact that is not something you can address from within PHP does NOT 
invalidate the fact that running that script on a secure server using 
OPEN SSL could be a problem

Lets put it another way. If you DONT run that script on an (insecure) 
ssl server, there is no issue. If you do there is. SO 'that script could 
be a problem'

You should get out more and stop being so stuck up your own smart ass.

Or are you a nymshifted stucklehead?


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#13393

On 4/10/2014 10:59 PM, Denis McMahon wrote:
> On Thu, 10 Apr 2014 21:58:01 -0400, Jerry Stuckle wrote:
>
>> On 4/10/2014 7:47 PM, The Natural Philosopher wrote:
>>> On 11/04/14 00:01, Denis McMahon wrote:
>
>>>> For example, the following php script as a web page has no exposure to
>>>> the OpenSSL vulnerability:
>
>>>> <?php echo "<!doctype html><html lang='en'><head><title>Test</title></
>>>> head><body><h1>Hello World</h1></body></html>"
>>>> ?>
>
>>> ER, it COULD if it was running on a secure server!!!
>
>> But that wouldn't be a PHP problem.  It would be an Apache problem.
>
> You expect him to comprehend the distinction following years of evidence
> to the contrary?
>

Good point, Denis.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#13379

Jerry Stuckle, 2014-04-10 13:52:

> On 4/10/2014 2:51 AM, Arno Welzel wrote:
>> Jerry Stuckle, 2014-04-09 19:37:
>>
>>> On 4/9/2014 11:43 AM, Christoph Michael Becker wrote:
>> [...]
>>>> ACK.  However, the Windows x86 builds of PHP 5.5.11 shipped OpenSSL
>>>> 1.0.1f (6 Jan 2014) and have been updated to ship OpenSSL 1.0.1g (7 Apr
>>>> 2014) just a few hours ago.  (The x64 builds are currently being worked
>>>> on.)  So obviously PHP's OpenSSL extension is affected by the
>>>> "heartbleed" bug (at least on Windows).
>>>>
>>>
>>> Does it?  Or does it mean they just want to keep up with the latest
>>> release?  And if it does affect PHP, what functions does it affect, and
>>> how does it affect them?
>>
>> I assume PHP does keep up with the latest release because they *are*
>> affected by the bug e.g. in stream_socket_enable_crypto().
>>
>>
> 
> You can ASS-U-ME all you want.  I go by the facts.  And if I were 

Oh you are so funny...

> concerned about PHP being involved, I would ask the OpenSSL people.

The fact is, that stream_socket_enable_crypto() allows to build a server
which listens on a socket to accept incoming SSL/TLS connections and
uses OpenSSL for this.

OpenSSL up to 1.0.1f has a now well known vulnerability for that use case.

Ask who ever you want. If you got the answers that prove all this wrong,
do the rest of us a favour and tell us.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#13382

On Thu, 10 Apr 2014 22:54:01 +0200, Arno Welzel wrote:

> The fact is, that stream_socket_enable_crypto() allows to build a server
> which listens on a socket to accept incoming SSL/TLS connections and
> uses OpenSSL for this.
> 
> OpenSSL up to 1.0.1f has a now well known vulnerability for that use
> case.
> 
> Ask who ever you want. If you got the answers that prove all this wrong,
> do the rest of us a favour and tell us.

Yes, but for that issue to affect your (or my, or Jerry's) code, we'd 
have had to write our own SSL/TLS enabled server in PHP.

And for that issue to affect anyone elses code, they'd have had to write 
their own SSL/TLS enabled server in PHP.

So this comes back to: The "heartbleed" exploit will only affect your php 
code if your php code is linked against the exploitable OpenSSL libraries 
*AND* your code calls functions in those libraries that expose the 
exploits.

And to know that you need to know which functions of the libraries are 
exploitable, and whether your code calls those functions. It's impossible 
for anyone, without reviewing another persons code, to tell whether that 
other person's code is exposed to this exploit or not, and that is the 
point that I believe Jerry is trying to make, and that you are so 
abstrusely refusing to recognise.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#13391

Denis McMahon, 2014-04-11 00:45:

> On Thu, 10 Apr 2014 22:54:01 +0200, Arno Welzel wrote:
> 
>> The fact is, that stream_socket_enable_crypto() allows to build a server
>> which listens on a socket to accept incoming SSL/TLS connections and
>> uses OpenSSL for this.
>>
>> OpenSSL up to 1.0.1f has a now well known vulnerability for that use
>> case.
>>
>> Ask who ever you want. If you got the answers that prove all this wrong,
>> do the rest of us a favour and tell us.
> 
> Yes, but for that issue to affect your (or my, or Jerry's) code, we'd 
> have had to write our own SSL/TLS enabled server in PHP.
> 
> And for that issue to affect anyone elses code, they'd have had to write 
> their own SSL/TLS enabled server in PHP.
> 
> So this comes back to: The "heartbleed" exploit will only affect your php 
> code if your php code is linked against the exploitable OpenSSL libraries 
> *AND* your code calls functions in those libraries that expose the 
> exploits.

That's correct.

> And to know that you need to know which functions of the libraries are 
> exploitable, and whether your code calls those functions. It's impossible 
> for anyone, without reviewing another persons code, to tell whether that 
> other person's code is exposed to this exploit or not, and that is the 
> point that I believe Jerry is trying to make, and that you are so 
> abstrusely refusing to recognise.

Of course not *every* PHP based application is affected by the OpenSSL bug.

But I refuse to assume the opposite that everything is OK as long as no
one exactly can describe, how the OpenSSL bug may affect PHP
applications. Because concerning PHP in general there *is* a problem
which *can* affect PHP based applications as long as you use a PHP
version without updated OpenSSL libraries.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web