WikiLeaks CIA Exploits: FreeBSD References Within

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

WikiLeaks CIA Exploits: FreeBSD References Within

grarpamp
https://search.wikileaks.org/?q=freebsd

Currently returns many pages similarly named...

"Shell Code Database
This page includes local links to a shellcode
database discovered at shell-storm.org."
(And a pentest report mention from much older HBGary.
Plus some other unlikely miscellaneous hits.)

As this is only part 1 of a supposedly multipart release
of potentially new exploits, it makes sense to establish
ongoing search and review of this dataset for any as yet
unfixed exploits.

Included as fyi on cc: questions@ and hackers@ .
Discussion is likely better moved in reply to just security@ ,
with reporting of any actual unfixed exploits found
to the FreeBSD Bugzilla tracker.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: WikiLeaks CIA Exploits: FreeBSD References Within

Dag-Erling Smørgrav
grarpamp <[hidden email]> writes:
> https://search.wikileaks.org/?q=freebsd
>
> Currently returns many pages similarly named...
>
> "Shell Code Database
> This page includes local links to a shellcode
> database discovered at shell-storm.org."

That doesn't indicate a vulnerability.  Shell code is what you use to
exploit a remote code execution vulnerability once you've found it.  It
usually needs to be tailored to the target operating system, sometimes
to the exact environment and to the application used to inject it, so it
makes sense that a shell code database would reference FreeBSD.

> [...] it makes sense to establish ongoing search and review of this
> dataset for any as yet unfixed exploits.

Note to anyone thinking of getting involved in this: depending on your
jurisdiction and employment situation, downloading material from the CIA
dump may be illegal and / or a firing offense.  Simply browsing it
online may or may not be safe; get legal advice before you do.  IANAL.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: WikiLeaks CIA Exploits: FreeBSD References Within

grarpamp
On Wed, Mar 8, 2017 at 10:52 AM, Dag-Erling Smørgrav <[hidden email]> wrote:
> grarpamp <[hidden email]> writes:
>> https://search.wikileaks.org/?q=freebsd
> That doesn't indicate a vulnerability.  Shell code is what you use to

Yep, sec folks are aware of the difference between
sample and exploit code, and vulnerabilities.
https://www.freebsd.org/security/advisories.html
http://shell-storm.org/shellcode/

The post wasn't meant to "indicate a vulnerability".
But as a heads up that maybe some might end up being
published there. On the other hand, there are countless eyes
on it, so OS vendors will find out in time,
even if they aren't eyeballing it themselves.

> legal advice

Let us all get legal advice before living, as it might entail risks ;)
Lots of sites offer a variety of advice for those facing risks.
Here are some related to employers, browsing, and law...
https://intelexit.org/ https://www.youtube.com/watch?v=fklxuoBXXqw
https://www.torproject.org/ https://geti2p.net/
https://www.eff.org/
IANAGPA, but they do exist.

(Btw, the pentest turned out to be old Nessus and Metasploit stuff.)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within)

Steven Chamberlain
In reply to this post by grarpamp
From this document (TOP SECRET//SI//NOFORN):
https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%20Requirements%20v1.1%20TOP%20SECRET.pdf

version 1.0 said:

| 8. (S//NF) [...] If RC4 is used, at least the first 1024
| bytes of the cryptostream must be discarded and may not be used

and that is exactly what FreeBSD's libc and in-kernel arc4random
implementations do.

version 1.1 received input from another agency:

| (C//SI//REL FVEY) Coordinated with NSA/CES.

and a new requirement was introduced:

| (TS//SI) 5.9: Added additional information about proper use of RC4.

| 9. (TS//SI) Further than stated above, if RC4 is used the first 3072
| bytes of the cryptostream must be discarded and may not be used.

I think you should take that to mean, the NSA has, or suspects someone
else to have, a practical attack on RC4 when being used as FreeBSD does
currently.  The document seems 4-5 years old already as it prohibits use
of RC4 at all from 2014 onward.

Please consider switching to ChaCha20 in the long term (kern/182610),
but right now, at least increase the amount of early keystream that is
discarded.

Many thanks,
Regards,
--
Steven Chamberlain
[hidden email]

arc4random.patch (1K) Download Attachment
signature.asc (662 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness (was: WikiLeaks CIA Exploits: FreeBSD References Within)

Dewayne Geraghty-5
On 14 March 2017 at 09:06, Steven Chamberlain <[hidden email]> wrote:

> From this document (TOP SECRET//SI//NOFORN):
> <a href="https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%">https://wikileaks.org/ciav7p1/cms/files/NOD%20Cryptographic%
> 20Requirements%20v1.1%20TOP%20SECRET.pdf
>
> version 1.0 said:
>
> | 8. (S//NF) [...] If RC4 is used, at least the first 1024
> | bytes of the cryptostream must be discarded and may not be used
>
> and that is exactly what FreeBSD's libc and in-kernel arc4random
> implementations do.
>
> version 1.1 received input from another agency:
>
> | (C//SI//REL FVEY) Coordinated with NSA/CES.
>
> and a new requirement was introduced:
>
> | (TS//SI) 5.9: Added additional information about proper use of RC4.
>
> | 9. (TS//SI) Further than stated above, if RC4 is used the first 3072
> | bytes of the cryptostream must be discarded and may not be used.
>
> I think you should take that to mean, the NSA has, or suspects someone
> else to have, a practical attack on RC4 when being used as FreeBSD does
> currently.  The document seems 4-5 years old already as it prohibits use
> of RC4 at all from 2014 onward.
>
> Please consider switching to ChaCha20 in the long term (kern/182610),
> but right now, at least increase the amount of early keystream that is
> discarded.
>
> Many thanks,
> Regards,
> --
> Steven Chamberlain
> [hidden email]
>

Thanks Steven.  I wasn't aware that OpenBSD was 3.5+ years ahead of the
curve in terms of securing against RC4 weaknesses, compared to FreeBSD.
Perhaps they have access to a mole ;)

The pointer to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610
probably needs a push along. (or a local patch, which mostly applied to
/usr/src/lib/libc/gen/arc4random.c ; 2 of 13 hunks need a manual adjustment)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Steven Chamberlain
In reply to this post by Steven Chamberlain
Steven Chamberlain wrote:
> Please consider switching to ChaCha20 in the long term (kern/182610),
> but right now, at least increase the amount of early keystream that is
> discarded.

Many, many thanks delphij+so for applying the latter change so quickly!

Also it is great to see INHERIT_ZERO was added to mmap(2)!

(It will avoid the overhead of a getpid(2) syscall on every call to
arc4random_buf(3) to determine if reseeding is needed.  That wasn't
guaranteed reliable anyway;  if you have forked twice, then by
chance/manipulation the new pid *could* be the same as the ancestor's).

Thanks!
Regards,
--
Steven Chamberlain
[hidden email]

signature.asc (662 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Andrey Chernov
On 15.03.2017 16:06, Steven Chamberlain wrote:
> Also it is great to see INHERIT_ZERO was added to mmap(2)!

It is not so great. For a program which forks very often zeroing even
one page will be slowdown. It will be better and faster to implement it
as fork syscall wrapper setting single variable, as it already done for
threaded lib.




signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Dag-Erling Smørgrav
Andrey Chernov <[hidden email]> writes:
> Steven Chamberlain <[hidden email]> writes:
> > Also it is great to see INHERIT_ZERO was added to mmap(2)!
> It is not so great. For a program which forks very often zeroing even
> one page will be slowdown.

Wouldn't it be possible to just set up the page entry but leave it
unmapped, so that it is paged in (and zeroed if necessary) on first
access?  Thus, a process that uses arc4random() and fork()s would not
incur a penalty until (and unless) the child uses arc4random() too.

> It will be better and faster to implement it as fork syscall wrapper
> setting single variable, as it already done for threaded lib.

fork() and vfork() and pdfork() and...  From a security point of view, I
prefer to have it in a single place.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Konstantin Belousov
On Thu, Mar 16, 2017 at 01:48:45PM +0100, Dag-Erling Sm??rgrav wrote:

> Andrey Chernov <[hidden email]> writes:
> > Steven Chamberlain <[hidden email]> writes:
> > > Also it is great to see INHERIT_ZERO was added to mmap(2)!
> > It is not so great. For a program which forks very often zeroing even
> > one page will be slowdown.
>
> Wouldn't it be possible to just set up the page entry but leave it
> unmapped, so that it is paged in (and zeroed if necessary) on first
> access?  Thus, a process that uses arc4random() and fork()s would not
> incur a penalty until (and unless) the child uses arc4random() too.
This is how the forking code works, without any additional coding,
for the INHERIT_ZERO regions as well.

>
> > It will be better and faster to implement it as fork syscall wrapper
> > setting single variable, as it already done for threaded lib.
>
> fork() and vfork() and pdfork() and...  From a security point of view, I
> prefer to have it in a single place.
>
> DES
> --
> Dag-Erling Sm??rgrav - [hidden email]
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Xin LI-5
In reply to this post by Andrey Chernov
On Wed, Mar 15, 2017 at 1:13 PM, Andrey Chernov <[hidden email]> wrote:
> On 15.03.2017 16:06, Steven Chamberlain wrote:
>> Also it is great to see INHERIT_ZERO was added to mmap(2)!
>
> It is not so great. For a program which forks very often zeroing even
> one page will be slowdown. It will be better and faster to implement it
> as fork syscall wrapper setting single variable, as it already done for
> threaded lib.

I think it's exactly what it was done (and unlike a fork wrapper, the
zeroing only happens on-demand, i.e. when the page is first touched).

Cheers,
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Andrey Chernov
On 16.03.2017 20:24, Xin LI wrote:

> On Wed, Mar 15, 2017 at 1:13 PM, Andrey Chernov <[hidden email]> wrote:
>> On 15.03.2017 16:06, Steven Chamberlain wrote:
>>> Also it is great to see INHERIT_ZERO was added to mmap(2)!
>>
>> It is not so great. For a program which forks very often zeroing even
>> one page will be slowdown. It will be better and faster to implement it
>> as fork syscall wrapper setting single variable, as it already done for
>> threaded lib.
>
> I think it's exactly what it was done (and unlike a fork wrapper, the
> zeroing only happens on-demand, i.e. when the page is first touched).

Theo kindly explained that zeroing whole page instead of single variable
suits to his newest arc4random better, since clears two structs at once
(including ChaCha state), making some form of backward secrecy.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Dag-Erling Smørgrav
Andrey Chernov <[hidden email]> writes:
> Theo kindly explained that zeroing whole page instead of single variable
> suits to his newest arc4random better, since clears two structs at once
> (including ChaCha state), making some form of backward secrecy.

Yes, avoiding leaking key material to child processes would be useful
for more than just arc4random.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: arc4random weakness

Dag-Erling Smørgrav
In reply to this post by Konstantin Belousov
Konstantin Belousov <[hidden email]> writes:
> Dag-Erling Smørgrav <[hidden email]> writes:
> > Wouldn't it be possible to just set up the page entry but leave it
> > unmapped, so that it is paged in (and zeroed if necessary) on first
> > access?  Thus, a process that uses arc4random() and fork()s would not
> > incur a penalty until (and unless) the child uses arc4random() too.
> This is how the forking code works, without any additional coding,
> for the INHERIT_ZERO regions as well.

Well then I don't see the problem...  I just assumed from ache@'s
objection that it wasn't the case.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[hidden email]"