Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Victor Sudakov]

Roger Marquis wrote:
> > In my case, no page is involved, just the FreeOTP app on my Android
> > phone (which is less convenient than a sheet of paper with OPIE
> > passwords, but I can live with that).
> 
> FreeOTP and FreeOTP+ are IMO the best OTP apps out there.  They require
> no privacy invading "push" notifications and are open source.  

Would you rely on security/pam_google_authenticator+FreeOTP as the
*single* authentication for ssh (not as an extra authentication factor)?
In other words, as a "sufficient" PAM module?

> Just wish
> more sites would publish numeric codes instead of gimmicky QR codes.

Oh, I love the QR codes google-authenticator generates in
character-based terminals. Very stylish, and convenient to scan with
the FreeOTP app.

Do you know if there is a FreeOTP generator for the FreeBSD console,
like /usr/bin/otp-md5 ?
> 
> That said there are still plenty of us who also use OPIE.  The passcodes
> are a solid T/HOTP fallback, aren't subject to seizure by border agents
> having a bad day, can be easily copied and stored on paper and have zero
> dependencies on 3rd parties.
> 
> That's not to say that OPIE should be kept in base though.  There's
> already way too much unused legacy cruft in FreeBSD base.  Ports are the
> right tool for that job.

Is there a way to keep some software in ports, if the original project is
dead?


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[grarpamp]

On 6/18/19, Gordon Tetlow  wrote:
> On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
>> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
>> NFLX-2019-001
>>
>> Date Entry Created: 20190107
>> Preallocated to nothing?
>> Or witheld...?

> MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
> when to assign and disclose them. The 2019-01-07 date is when MITRE
> allocated a block of CVEs to FreeBSD, not when they are assigned to an
> issue. We generally get a block in the beginning of each year.

So preallocated to nothing, ok very well, no problem,
priors amended herein as such, thx.

As it is not in the current .md, when was the issue
discovered by Netflix / Looney?

> discussion around disclosure policies

In today's world of parallel discovery, leaks, sec org infiltration by
adversary, surveillance, no crypto, rapid automated exploit, etc...
to wait for patch, polish, and press release advert, to not disclose,
afford users local action up to immediate offlining for safety and wait,
to draw upon entire community pool that has time*ability to fix... is
thought by many [users] as irresponsible to users. There is no tone. And
of course this one isn't currently a remote or local root. But what if it was...
For those interested or new, there's lots of historical discussion with
and without tone that can be found on any seclist, yet is no universal..

Having just noted these...

https://www.freebsd.org/security/
https://www.freebsd.org/security/charter.html
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/security/

The charter last marked current 2002... is there any actual and
posted mandatory timeliness disclosure trigger component?
One that gets overall reviewed for user input say every N-years?
Perhaps something more security focused than the general...

https://www.research.net/r/freebsd2019


Hack happily :)


Netflix dedication to FreeBSD much appreciated by many too.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Roger Marquis]

In my case, no page is involved, just the FreeOTP app on my Android
phone (which is less convenient than a sheet of paper with OPIE
passwords, but I can live with that).


FreeOTP and FreeOTP+ are IMO the best OTP apps out there.  They require
no privacy invading "push" notifications and are open source.  Just wish
more sites would publish numeric codes instead of gimmicky QR codes.

That said there are still plenty of us who also use OPIE.  The passcodes
are a solid T/HOTP fallback, aren't subject to seizure by border agents
having a bad day, can be easily copied and stored on paper and have zero
dependencies on 3rd parties.

That's not to say that OPIE should be kept in base though.  There's
already way too much unused legacy cruft in FreeBSD base.  Ports are the
right tool for that job.

But OPIE is still used, can be updated relatively easily, and should be
kept somewhere accessible for security-conscious end-users.  To
eliminate it would only benefit those with commercial interests in
proprietary and hosted (vendor lock-in) MFA solutions.

IMO,
Roger Marquis
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Victor Sudakov]

Robert Simmons wrote:
> 
> To throw a new wrinkle in the equation: Google Authenticator codes can be
> intercepted by a phishing page. 

In my case, no page is involved, just the FreeOTP app on my Android
phone (which is less convenient than a sheet of paper with OPIE
passwords, but I can live with that).

> U2F protocol is even better, and can't be
> intercepted via phishing.
> 
> There are U2F libraries in ports.
> 
> https://en.wikipedia.org/wiki/Universal_2nd_Factor

U2F (and Yubikey) require purchase of hardware devices. In this sense,
they are not replacements for OPIE, which is a pure software solution. 

Back to my original question.

1. Is it safe to keep OPIE in the base system? Its upstream project
is gone. It is not IPv6 ready. It uses MD5.

2. If OPIE is not safe anymore, which is a good software replacement? 

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[Shawn Webb]

On Tue, Jun 18, 2019 at 04:55:35PM -0700, Gordon Tetlow wrote:
> On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
> > https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
> > NFLX-2019-001
> > 
> > Date Entry Created: 20190107
> > Preallocated to nothing?
> > Or witheld under irresponsible disclosure thus keeping
> > users vulnerable to leaks, parallel discovery, and exploit
> > for at least five months more than necessary, and
> > unaware thus unable to consider potential local mitigations?
> 
> Other than the inappropriate tone, there is a reasonable question here.
> MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
> when to assign and disclose them. The 2019-01-07 date is when MITRE
> allocated a block of CVEs to FreeBSD, not when they are assigned to an
> issue. We generally get a block in the beginning of each year.
> 
> If you would like to have an actual discussion around disclosure
> policies, I'm happy to have one, but by your tone above, I don't think
> there is any reason to do so. It seems unlikely you are open to
> debate in a fashion that would be productive.

Hey Gordon,

Thank you for your reply, and especially for the respectful tone. I
hope to drive a further positive discussion in the goal of enhanced
transparency.

It appears that Netflix's advisory (as of this writing) does not
include a timeline of events. Would FreeBSD be able to provide its
event timeline with regards to CVE-2019-5599?

Were any FreeBSD derivatives given advanced notice? If so, which ones?

Thanks for your time, resources, and continued correspondence.

Thanks again,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2


signature.asc
Description: PGP signature

Re: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[Gordon Tetlow]

On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
> NFLX-2019-001
> 
> Date Entry Created: 20190107
> Preallocated to nothing?
> Or witheld under irresponsible disclosure thus keeping
> users vulnerable to leaks, parallel discovery, and exploit
> for at least five months more than necessary, and
> unaware thus unable to consider potential local mitigations?

Other than the inappropriate tone, there is a reasonable question here.
MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
when to assign and disclose them. The 2019-01-07 date is when MITRE
allocated a block of CVEs to FreeBSD, not when they are assigned to an
issue. We generally get a block in the beginning of each year.

If you would like to have an actual discussion around disclosure
policies, I'm happy to have one, but by your tone above, I don't think
there is any reason to do so. It seems unlikely you are open to
debate in a fashion that would be productive.

Thanks,
Gordon
Hat: Security Officer
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[grarpamp]

https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
NFLX-2019-001

Date Entry Created: 20190107
Preallocated to nothing?
Or witheld under irresponsible disclosure thus keeping
users vulnerable to leaks, parallel discovery, and exploit
for at least five months more than necessary, and
unaware thus unable to consider potential local mitigations?

Older references...

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=freebsd
https://nvd.nist.gov/vuln/search/results?form_type=Basic_type=overview=freebsd_type=all
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: TCP SACK (CVE-2019-5599)

[Cy Schubert]

On June 18, 2019 7:57:09 AM PDT, hiren via freebsd-security 
 wrote:
>On 06/18/19 at 10:33P, mike tancsa wrote:
>> Hi all,
>> With respect to the bugs describe in
>>
>https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> *
>>   SACK Slowness (FreeBSD 12 using the RACK TCP Stack)
>[snip]
>> 
>> **
>> 
>> *How does I know if this is enabled in my default kernel on RELENG_12
>?
>> There is some vague mention in various forums this is not the default
>on
>> FreeBSD ? Can anyone shed more light as to how this does/does not
>impact
>> FreeBSD ?
>
>RACK is one of the tcp stacks ($src/sys/netinet/tcp_stacks) and not
>enabled by default.
>
>So, by default, FreeBSD is not affected, afaict. This advisory is for
>when you do use RACK.
>
>Cheers,
>Hiren

They post a workaround patch in their advisory. As RACK is their contribution, 
I suppose one of their people who are committers might want to commit it.


-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert 
FreeBSD UNIX:  Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[hiren via freebsd-security]

On 06/18/19 at 04:36P, Stefan Bethke wrote:
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> 
> Are stock kernels/configurations affected? If so, will a fix or workaround be 
> incorporated?

RACK is still not default stack so FreeBSD is not affected.

Cheers,
Hiren


signature.asc
Description: PGP signature

Re: TCP SACK (CVE-2019-5599)

[hiren via freebsd-security]

On 06/18/19 at 10:33P, mike tancsa wrote:
> Hi all,
> With respect to the bugs describe in
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> *
>   SACK Slowness (FreeBSD 12 using the RACK TCP Stack)
[snip]
> 
> **
> 
> *How does I know if this is enabled in my default kernel on RELENG_12 ?
> There is some vague mention in various forums this is not the default on
> FreeBSD ? Can anyone shed more light as to how this does/does not impact
> FreeBSD ?

RACK is one of the tcp stacks ($src/sys/netinet/tcp_stacks) and not
enabled by default.

So, by default, FreeBSD is not affected, afaict. This advisory is for
when you do use RACK.

Cheers,
Hiren


signature.asc
Description: PGP signature

Re: TCP SACK (CVE-2019-5599)

[Lowell Gilbert]

mike tancsa  writes:

> *How does I know if this is enabled in my default kernel on RELENG_12 ?
> There is some vague mention in various forums this is not the default on
> FreeBSD ? Can anyone shed more light as to how this does/does not impact
> FreeBSD ?

If the net.inet.tcp.functions_default sysctl doesn't list "rack", you
don't have to worry about it. As far as I can see from a quick look at
my source tree, you would have to load a module to use it.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

[Stefan Bethke]

https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md

Are stock kernels/configurations affected? If so, will a fix or workaround be 
incorporated?


Thanks,
Stefan

-- 
Stefan BethkeFon +49 151 14070811

___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

TCP SACK (CVE-2019-5599)

[mike tancsa]

Hi all,

With respect to the bugs describe in

https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md

*
*


  SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

*Description:* It is possible to send a crafted sequence of SACKs which
will fragment the RACK send map. An attacker may be able to further
exploit the fragmented send map to cause an expensive linked-list walk
for subsequent SACKs received for that same TCP connection.

*Workaround #1:* Apply the patch split_limit.patch

 and
set the |net.inet.tcp.rack.split_limit| sysctl to a reasonable value to
limit the size of the SACK table.

*Workaround #2:* Temporarily disable the RACK TCP stack.

(Note that either workaround should be sufficient on its own. It is not
necessary to apply both workarounds.)

**

*How does I know if this is enabled in my default kernel on RELENG_12 ?
There is some vague mention in various forums this is not the default on
FreeBSD ? Can anyone shed more light as to how this does/does not impact
FreeBSD ?
*

*
*

*    ---Mike
*


___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Dan Langille]

> On Jun 18, 2019, at 9:02 AM, Robert Simmons  wrote:
> 
> On Tue, Jun 18, 2019, 04:01 Victor Sudakov  wrote:
> 
>> Dear Colleagues,
>> 
>> I've used OPIE for many years (and S/Key before that) to login to my
>> system from untrusted terminals (cafes, libraries etc).
>> 
>> Now I've read an opinion that OPIE is outdated (and indeed its upstream
>> distribution is gone) and that pam_google_authenticator would be more
>> secure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237270
>> 
>> Is that truly so? With 20 words in OPIE and only 6 digits in
>> pam_google_authenticator, how strong is pam_google_authenticator against
>> brute force and other attacks?

> Victor,
> 
> To throw a new wrinkle in the equation: Google Authenticator codes can be
> intercepted by a phishing page. U2F protocol is even better, and can't be
> intercepted via phishing.
> 
> There are U2F libraries in ports.
> 
> https://en.wikipedia.org/wiki/Universal_2nd_Factor
> 
> Cheers,
> Rob
> 


If my Google Authenticator codes are on my phone, and I'm entering them into my 
ssh session, how is a phishing page involved?

— 
Dan Langille
http://langille .org/





___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Robert Simmons]

I am thinking about it from the perspective of having one single 2fa across
as many systems as possible.

On Tue, Jun 18, 2019, 09:09 Robert Simmons  wrote:

> You are correct for SSH.
>
> On Tue, Jun 18, 2019, 09:07 Dan Langille  wrote:
>
>> On Jun 18, 2019, at 9:02 AM, Robert Simmons  wrote:
>>
>> On Tue, Jun 18, 2019, 04:01 Victor Sudakov  wrote:
>>
>> Dear Colleagues,
>>
>> I've used OPIE for many years (and S/Key before that) to login to my
>> system from untrusted terminals (cafes, libraries etc).
>>
>> Now I've read an opinion that OPIE is outdated (and indeed its upstream
>> distribution is gone) and that pam_google_authenticator would be more
>> secure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237270
>>
>> Is that truly so? With 20 words in OPIE and only 6 digits in
>> pam_google_authenticator, how strong is pam_google_authenticator against
>> brute force and other attacks?
>>
>>
>> Victor,
>>
>> To throw a new wrinkle in the equation: Google Authenticator codes can be
>> intercepted by a phishing page. U2F protocol is even better, and can't be
>> intercepted via phishing.
>>
>> There are U2F libraries in ports.
>>
>> https://en.wikipedia.org/wiki/Universal_2nd_Factor
>>
>> Cheers,
>> Rob
>>
>>
>>
>> If my Google Authenticator codes are on my phone, and I'm entering them
>> into my ssh session, how is a phishing page involved?
>>
>> —
>> Dan Langille
>> http://langille.org/
>>
>>
>>
>>
>>
>>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Robert Simmons]

You are correct for SSH.

On Tue, Jun 18, 2019, 09:07 Dan Langille  wrote:

> On Jun 18, 2019, at 9:02 AM, Robert Simmons  wrote:
>
> On Tue, Jun 18, 2019, 04:01 Victor Sudakov  wrote:
>
> Dear Colleagues,
>
> I've used OPIE for many years (and S/Key before that) to login to my
> system from untrusted terminals (cafes, libraries etc).
>
> Now I've read an opinion that OPIE is outdated (and indeed its upstream
> distribution is gone) and that pam_google_authenticator would be more
> secure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237270
>
> Is that truly so? With 20 words in OPIE and only 6 digits in
> pam_google_authenticator, how strong is pam_google_authenticator against
> brute force and other attacks?
>
>
> Victor,
>
> To throw a new wrinkle in the equation: Google Authenticator codes can be
> intercepted by a phishing page. U2F protocol is even better, and can't be
> intercepted via phishing.
>
> There are U2F libraries in ports.
>
> https://en.wikipedia.org/wiki/Universal_2nd_Factor
>
> Cheers,
> Rob
>
>
>
> If my Google Authenticator codes are on my phone, and I'm entering them
> into my ssh session, how is a phishing page involved?
>
> —
> Dan Langille
> http://langille.org/
>
>
>
>
>
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: Untrusted terminals: OPIE vs security/pam_google_authenticator

[Robert Simmons]

Victor,

To throw a new wrinkle in the equation: Google Authenticator codes can be
intercepted by a phishing page. U2F protocol is even better, and can't be
intercepted via phishing.

There are U2F libraries in ports.

https://en.wikipedia.org/wiki/Universal_2nd_Factor

Cheers,
Rob

On Tue, Jun 18, 2019, 04:01 Victor Sudakov  wrote:

> Dear Colleagues,
>
> I've used OPIE for many years (and S/Key before that) to login to my
> system from untrusted terminals (cafes, libraries etc).
>
> Now I've read an opinion that OPIE is outdated (and indeed its upstream
> distribution is gone) and that pam_google_authenticator would be more
> secure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237270
>
> Is that truly so? With 20 words in OPIE and only 6 digits in
> pam_google_authenticator, how strong is pam_google_authenticator against
> brute force and other attacks?
>
>
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> 2:5005/49@fidonet http://vas.tomsk.ru/
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Untrusted terminals: OPIE vs security/pam_google_authenticator

[Victor Sudakov]

Dear Colleagues,

I've used OPIE for many years (and S/Key before that) to login to my
system from untrusted terminals (cafes, libraries etc).

Now I've read an opinion that OPIE is outdated (and indeed its upstream
distribution is gone) and that pam_google_authenticator would be more
secure: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237270

Is that truly so? With 20 words in OPIE and only 6 digits in
pam_google_authenticator, how strong is pam_google_authenticator against
brute force and other attacks?



-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature