What happened to the php56-5.6.23 security warning?

K

kjpetrie

For the last few days my server has reported that php56-5.6.23 is vulnerable, and yesterday PHP released 5.6.24. Today I checked ports for an upgrade but there isn't one yet.

However, the warning on PHP has now vanished and is no longer being reported. Any idea why that would be?
 
How does that affect what happened to the e-mail warning? pkg audit shows no warning now, but I don't know what it would have shown two days ago when I was receiving warnings for this package by e-mail every morning.

My question is "why has the warning disappeared?" Without an explanation my confidence in the database (whether accessed by pkg audit or e-mailed warnings) is undermined. Moreover, PHP have issued a security upgrade on the same day this warning disappeared, but this has not appeared as a port yet.

The point is a package was flagged as insecure but no longer is, and the authors have acknowledged the insecurity, but FreeBSD has dropped the warning.

I am concerned.
 
Thanks for that URL. Nothing is hidden from those who know where to look!

I'm still puzzled by this, though. It looks as if a decision was taken not to warn because a patch wasn't available - which seems a slightly dubious approach to security, and then it was decided to cancel the warning altogether, on the day PHP issued a security upgrade, as it happens.

It does have something of the look of 'removing' the odd noise from the engine by turning the radio up!
 
The more I read the more worried I become. You seem to think I want to fix my own server. That is not the case. I don't think anything I've written uses the affected variable.

My concern is that it appears FreeBSD has chosen to remove the vulnerability from its database rather than issuing the fix and I don't understand why anyone would do that. It's about being able to trust the database.
 
On a scale of 1 to 10 where 1 is complete ignorance and 10 is master knowledge, how do you rate your understanding of the httpoxy issue?

It appears to me that for you that the actual issue is irrelevant and you're "concerned" that a vulnerability was cancelled but didn't investigate why it was cancelled. I can think of several logical reasons to back it out, so the mere presence of a back-out isn't concerning to me personally. You *have* to understand each case before opining, no?
 
I can only know what has been shown to me: namely
"Remove HTTPoxy entry in vuxml until a we know if upstream vendors will
patch this so things aren't marked vulnerable forever."

The next day it was shown as cancelled with no further explanation, and PHP issued a patched version, so the reason given ceased to apply.

As for what I understand, on a scale of 1 to 10 I don't know, but I understand this is likely to affect users who use standard libraries to implement functionality, or use certain functions (eg getenv()) to access data, or use the $_SERVER['HTTP_PROXY'] autoglobal. It looks serious enough to justify a warning and a patch as soon as one is available.

As for my alleged failure to investigate, I searched for information in search engines and found none, so I asked for an explanation here, and none has been given. I would have thought when removing a warning like this it is self-evident that there should be a good reason for doing so which is available to users so they can be reassured the threat isn't real or has been dealt with in some way.

I'm concerned because, despite my question I'm just directed to information about the bug and the removal of the warning, none of which seems to explain why, other than it would have been untidy to leave the warning up if upstream fixes were not forthcoming, which in the case of PHP they were.

Users need to see and understand the rationale for decisions which affect reliability and security in order to have confidence in them. Is that such an unreasonable position?
 
While it would have been nice to have an explanation in the commit message, you're making some assumptions. The most obviously one is the original commit is correct and the cancellation commit is wrong or nefarious. It could just as easily be the original commit never should have been made. You aren't in a position to judge since you have a very poor understanding of the allegedly vulnerability and how it affects ports and framework. You were directed elsewhere to help you educate yourself on the topic that concerns you, just as you were given the link to vuxml.

The same people are responsible for both commits, so you either trust them both or neither. Apparently until this point you trusted vuxml, so why change now?

You need to ask the person responsible for both commits directly (brnrd@) or perhaps members of the ports-sec team like feld@. Why would you think random users on the forum would have more insight than can be seen on the commit log? As these topics can be quite complex with subtle hooks, they often require in-depth knowledge of the ports system itself and I would NOT expect in-depth explanations of rationales an decisions for each commit, some of which can number 10 in a day. I do think the position is a bit unreasonable -- you had trust to this point, what has been done that undermines that? Are you thinking they are having bad judgement and the users-at-large with no security background or expert knowledge of framework will make better decisions if they are exposed to the rationale? I don't get any of this.
 
Nor do I. I'm just an ordinary user who doesn't like to see unexplained inconsistency where security is concerned. This is the Forum. I have raised the issue here in the expectation it will be seen by those who need to see it or can explain why it isn't a problem.
 
Does the security team really have to explain themselves in any other way? The commit log of security/vuxml already shows what was done and why. Granted, pkg-audit(8) could be a bit more clear of where it gets its information and how to dig out the commit history of the VuXML database but that information is not hidden either in any way.
 
kjpetrie said:
in the expectation it will be seen by those who need to see it or can explain why it isn't a problem.
Click to expand...

That's a bad expectation to have. While "the forum" counts a few developers among it's members, it is in no way required or official. If you want to get information from the ports security team, you subscribe to their mail list. That's the only official method.

In other words: the forum is the place to talk to other users like yourself. You are seeking developers and this is not the place for that. (Note that some of these other users are quite knowledgeable and often very helpful, but the forum is not best venue for *every* type of question. Usually that is where mail lists come in).
 
To me it was legitimate to have some skepticism about the handling of the security issue regarding php56. A warning was issued and subsequently withdrawn.
Today it has been fixed with a new version of php56.
http://www.vuxml.org/freebsd/b6402385-533b-11e6-a7bd-14dae9d210b8.html said:
Fixed bug #72573 (HTTP_PROXY is improperly trusted by some PHP libraries and applications).
Click to expand...

In the meantime cpm@ shed some light with his link to https://httpoxy.org/ while marino@ bashed the OPs lack of knowledge. The forum is open for asking questions. Having questions implies some need for information. There was no need to be personal. The hint to use the mailing list would have been sufficient.

Obviously the warning was issued too early, but the fix was not ready, while there was a real issue. Reason enough to ask on the forum.

My 2 cents.
 
getopt said:
marino@[/USER] bashed the OPs lack of knowledge.
Click to expand...
I did not. The OP was looking for information and people told him/her where to get it. I did think somebody should actually go learn about an issue before going berserk on it. I believe the same about any person on any topic. That's not "bashing", it's just common sense.

P.S. Thanks for conveniently forgetting that I pointed him/her to the vuxml logs. I guess that didn't count.
 
You must log in or register to reply here.
Back
Top