Reported version numbers of base openssl and sshd

[Roger Eddins]

Dear Maintainers,



Thank you for your excellent efforts in maintaining the FreeBSD code base.



Question: Could version number obfuscation be added to openssl and sshd or
have the proper relative patch version number reported from the binaries in
the base system?



Reasoning: PCI compliance is becoming an extreme problem due to scanning
false positives from certain vendors and a big time waster with older
FreeBSD releases reporting the original base version number even after patch
updates. This is requiring us to compile/run openssl port and
openssh-portable creating a highly unnecessary maintenance burden on our
admins when the package binaries would be sufficient if the these core base
components would report the latest version number. OF course, blocking the
scanning engines on certain ports is an easy trick but that doesn't solve
the root cause of the problem. We have a snowflake type environment for
custom hosting solutions so that hopefully gives a good picture of why using
ports for these core components is so time consuming.



If the official stance is to use openssl port and openssh-portable just so
the FreeBSD OS can report back the latest version number to PCI scanning
engines, sobeit but makes little sense at least in the context we exist in
and interfacing with PCI compliance vendors.



Thank you,

Roger Eddins

_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Ngie Cooper]

(CCing the current maintainers for OpenSSL and ssh)

> On Oct 5, 2016, at 00:16, Roger Eddins <ro...@purplecat.net> wrote:
>
> Dear Maintainers,
>
> Thank you for your excellent efforts in maintaining the FreeBSD code base.
>
> Question: Could version number obfuscation be added to openssl and sshd or
> have the proper relative patch version number reported from the binaries in
> the base system?
>
> Reasoning: PCI compliance is becoming an extreme problem due to scanning
> false positives from certain vendors and a big time waster with older
> FreeBSD releases reporting the original base version number even after patch
> updates. This is requiring us to compile/run openssl port and
> openssh-portable creating a highly unnecessary maintenance burden on our
> admins when the package binaries would be sufficient if the these core base
> components would report the latest version number. OF course, blocking the
> scanning engines on certain ports is an easy trick but that doesn't solve
> the root cause of the problem. We have a snowflake type environment for
> custom hosting solutions so that hopefully gives a good picture of why using
> ports for these core components is so time consuming.
>
> If the official stance is to use openssl port and openssh-portable just so
> the FreeBSD OS can report back the latest version number to PCI scanning
> engines, sobeit but makes little sense at least in the context we exist in
> and interfacing with PCI compliance vendors.

I think this request sounds reasonable. I don't know how difficult it might be or what exactly you have in mind version number wise.. But I'm guessing you have a straightforward idea that could be described.
Thanks!
-Ngie

[Jung-uk Kim]

On 10/04/2016 18:21, Ngie Cooper wrote:
> (CCing the current maintainers for OpenSSL and ssh)
>
>> On Oct 5, 2016, at 00:16, Roger Eddins <ro...@purplecat.net> wrote:
>>
>> Dear Maintainers,
>>
>> Thank you for your excellent efforts in maintaining the FreeBSD code base.
>>
>> Question: Could version number obfuscation be added to openssl and sshd or
>> have the proper relative patch version number reported from the binaries in
>> the base system?
>>
>> Reasoning: PCI compliance is becoming an extreme problem due to scanning
>> false positives from certain vendors and a big time waster with older
>> FreeBSD releases reporting the original base version number even after patch
>> updates. This is requiring us to compile/run openssl port and
>> openssh-portable creating a highly unnecessary maintenance burden on our
>> admins when the package binaries would be sufficient if the these core base
>> components would report the latest version number. OF course, blocking the
>> scanning engines on certain ports is an easy trick but that doesn't solve
>> the root cause of the problem. We have a snowflake type environment for
>> custom hosting solutions so that hopefully gives a good picture of why using
>> ports for these core components is so time consuming.
>>
>> If the official stance is to use openssl port and openssh-portable just so
>> the FreeBSD OS can report back the latest version number to PCI scanning
>> engines, sobeit but makes little sense at least in the context we exist in
>> and interfacing with PCI compliance vendors.
>
> I think this request sounds reasonable. I don't know how difficult it might be or what exactly you have in mind version number wise.. But I'm guessing you have a straightforward idea that could be described.

As an OpenSSL maintainer for the base, I always try to merge the latest
OpenSSL releases. For releng branches, so@ is in total control.

Jung-uk Kim

[Dag-Erling Smørgrav]

"Roger Eddins" <ro...@purplecat.net> writes:
> Question: Could version number obfuscation be added to openssl and sshd or
> have the proper relative patch version number reported from the binaries in
> the base system?
>
> Reasoning: PCI compliance is becoming an extreme problem due to scanning
> false positives from certain vendors and a big time waster with older
> FreeBSD releases reporting the original base version number even after patch
> updates.

I've been asked this before. My answer was that either the tools or the
people wielding them are deficient, and I haven't changed my mind.

How do they handle RHEL?

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Roger Eddins <sup...@purplecat.net> writes:
> [...] Across the board we are finding other processes in commerce
> tools rejecting transactions due to version number deficiencies and
> the problem is growing rapidly. My hope would be that the team would
> reconsider the version number question as it is the biggest deficiency
> we experience daily using the FreeBSD OS.

Once again: how do they handle RHEL? Because Red Hat, the 800-pound
gorilla of the Open Source world, does the same thing that we do:
backport patches without bumping the version number. And in fact, they
do *less* than we do, because for OpenSSL and OpenSSH, we havea version
suffixes which should reflect the date of the last patch, so even an
automated scanner *can* be taught to distinguish a vulnerable machine
from a patched one - as long as secteam remembers to bump the suffix
when they patch the software.

[Roger Eddins]

Dag-Erling,

I agree with your premise 100% and it's true the tool wielders are taking the easy road out by simply doing a version check but that road may make sense from a bandwidth and CPU standpoint for their systems and it comes down to perception more do than education.

I think from an accuracy standpoint it would make more academic sense to report an updated version number or at least a build number so the scanners can make an intelligent decision.

Across the board we are finding other processes in commerce tools rejecting transactions due to version number deficiencies and the problem is growing rapidly.  My hope would be that the team would reconsider the version number question as it is the biggest deficiency we experience daily using the FreeBSD OS.

Standing on a principle is great in concept but practical application sometimes overrides principle from a common sense perspective.

Thank you for your consideration on this important question.

Roger

Roger Eddins
Purplecat Networks Inc.
www.purplecat.net

[Vladimir Terziev]

In fact with RedHat the same issue exists.

Every time we have an audit (not PCI only), we have to explain the auditors the back-porting politics of RedHat and show them the change-log of the packages.

Roger, you can follow similar way. Your FreeBSD systems are at certain security patch-level (uname -r). You can show that to the auditors along to a log of the changes this patch-level incorporates in it.


Vladimir


On Oct 5, 2016, at 3:51 PM, Dag-Erling Smørgrav <d...@des.no>
wrote:

[pe...@purplecat.net]

Dag-Erling,

No doubt the scanners themselves are at primary fault, and we push back on
them vigorously, typically recommending our customers change scanning
companies for the worst cases, but this of course creates a lot of work. In
some instances our answer has simply been to firewall off their scanning
servers, which laughably results in a 'pass' from the pci compliance/audit
monkeys.

You are of course completely right about RHEL...And FreeBSD is so superior
in so many ways, it's not even a question--but having proper version numbers
reported would eliminate a lot of headaches for us (and give FreeBSD another
plus).

We would very much prefer ~not~ to display version information at all.
Having that as a variable in a configuration file would be a plus. Perhaps
one that defaults to actual versions running, with the ability to report
"non of your business."

Thanks for all you do for FreeBSD and its community.


Sincerely,

Peter Brezny
Purplecat Networks, Inc.
www.purplecat.net
828-250-9446


..

[Allan Jude]

On 2016-10-05 09:28, pe...@purplecat.net wrote:
> Dag-Erling,
>
> No doubt the scanners themselves are at primary fault, and we push back
> on them vigorously, typically recommending our customers change scanning
> companies for the worst cases, but this of course creates a lot of
> work. In some instances our answer has simply been to firewall off
> their scanning servers, which laughably results in a 'pass' from the pci
> compliance/audit monkeys.
>
> You are of course completely right about RHEL...And FreeBSD is so
> superior in so many ways, it's not even a question--but having proper
> version numbers reported would eliminate a lot of headaches for us (and
> give FreeBSD another plus).
>
> We would very much prefer ~not~ to display version information at all.
> Having that as a variable in a configuration file would be a plus.
> Perhaps one that defaults to actual versions running, with the ability
> to report "non of your business."

In the case of ssh, part of this is already controlled by a variable in
/etc/ssh/sshd_config

VersionAddendum FreeBSD-20140420

If you want to control the rest, you'd need to ask the upstream openssh
project. They use the version number information in the banner message
to enable compatibility tweaks.

>
> Thanks for all you do for FreeBSD and its community.
>
>
> Sincerely,
>
> Peter Brezny
> Purplecat Networks, Inc.
> www.purplecat.net
> 828-250-9446
>
>

> ...

> -----Original Message----- From: Dag-Erling Smørgrav
> Sent: Wednesday, October 5, 2016 8:51 AM
> To: Roger Eddins
> Cc: freebsd...@freebsd.org
> Subject: Re: Reported version numbers of base openssl and sshd
>
> Roger Eddins <sup...@purplecat.net> writes:
>> [...] Across the board we are finding other processes in commerce
>> tools rejecting transactions due to version number deficiencies and
>> the problem is growing rapidly. My hope would be that the team would
>> reconsider the version number question as it is the biggest deficiency
>> we experience daily using the FreeBSD OS.
>
> Once again: how do they handle RHEL? Because Red Hat, the 800-pound
> gorilla of the Open Source world, does the same thing that we do:
> backport patches without bumping the version number. And in fact, they
> do *less* than we do, because for OpenSSL and OpenSSH, we havea version
> suffixes which should reflect the date of the last patch, so even an
> automated scanner *can* be taught to distinguish a vulnerable machine
> from a patched one - as long as secteam remembers to bump the suffix
> when they patch the software.
>
> DES


--

Allan Jude