Was reading malloc(3) while chasing corruption suspects.
Does the presence of -Z imply that without it, programs
can be allocated dirty (non-zeroed) memory?
If so, it seems running with -Z would be prudent if one cares.
Therefore, what is the rough percent performance
impact of -Z compared to defau
> malloc(3) has never provided zeroed memory. If you need zeroed memory in C,
> you either need to zero it yourself using memset(3), or use calloc(3).
Or, in lieu, use -Z, presumably.
> What would be prudent as a developer (and is the default in CURRENT I
> believe) is to use J - it enforces the
http://www.freebsd.org/news/2012-compromise.html
http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key
This is not about this incident, but about why major opensource
projects need to be using a repository that has traceable, verifiable,
built-in
> Date: Mon, 7 Oct 2013 11:44:57 +0200
> From: Pawel Jakub Dawidek
> To: z...@lists.illumos.org
> Subject: Re: [zfs] [Review] 4185 New hash algorithm support
>
> On Mon, Oct 07, 2013 at 12:47:52AM +0100, Saso Kiselkov wrote:
>> Please review what frankly has become a bit of a large-ish feature:
>>
> https://lists.freebsd.org/pipermail/freebsd-security/2013-October/007226.html
http://www.freebsd.org/news/status/report-2013-07-2013-09.html#AES-NI-Improvements-for-GELI
http://www.freebsd.org/news/status/report-2013-07-2013-09.html#Reworking-random(4)
___
>>> Cryptografically signed ISO images
>>> http://docs.freebsd.org/cgi/mid.cgi?20140302172759.GA4728
>> If the use of [the signed] SHA-2[56] hashes don't provide enough
>> assurance that the ISO images are authentic can you explain the
>> crypto technology that you are looking for?
Signing the IS
Links regarding fde implementations, relevant re geli / gbde.
-- Forwarded message --
From: Darren Lasko
Date: Thu, Jun 26, 2014 at 6:03 PM
Subject: Re: [Cryptography] hardware vs software FDE (was Re:
Shredding a file on a flash-based file system?)
To: "Perry E. Metzger"
Cc: cr
re running, or simply delegate them and/or
any parameters of lesser importance to platform specific guides
on the Tor wiki.
> On 7 November 2014 00:20, grarpamp wrote:
>> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter wrote:
>>>
>>> FreeBSD still seems to use glob
On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell wrote:
> The critical stage is the boot ROM (BIOS) and the boot device.
> Once Linux has booted a lot is possible but too much has already taken
> place.
> A BIOS that allows booting from a Flash memory card must be trusted.
>
> Virtual machines may h
On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker wrote:
> At 03:12 PM 2/18/2015, grarpamp wrote:
>>Afaik, all vm's today simply pass through all drive commands.
>>
>>It seems a move all the BSD's and Linux could make today,
>>without waiting on untrustable h
On Fri, Feb 20, 2015 at 4:50 PM, grarpamp wrote:
> These for starters, then all the public hacker malware versions of
> the same thing both extant and coming...
Note the explicit references to FreeBSD and UFS in those links.
Linux and EXT FS as well. These OS are not immune to 0-day
and
These were the links I was referring to that
never made it past moderation/spam...
> Alfred Hegemeier saith:
> just encrypt the whole hard drive with Geli.
GELI works under your control for what you store on the
drive, and you can even enable the AES encryption feature
of the drive itself as a n
On Sat, Feb 21, 2015 at 8:41 AM, Kay Rydyger :
Please do not quote 200 lines of text just to insert your ten.
And if using the digest, use the original subject line. Else
it's lazy bad form at the expense of other readers of the list.
>> > Alfred Hegemeier saith:
>> > just encrypt the whole hard
> http://www.recover.co.il/SA-cover/SA-cover.pdf
Since the firmware rules over everything, all the spare sectors
for block reallocation must be considered too, not just the
service areas. Then there is the per sector CRC space that could
perhaps be reutilized if CRC is implemented as software func
On Tue, Feb 24, 2015 at 10:48 AM, Kay Rydyger wrote:
>
> The question was [... firmware spies]
> The answer is [...] to encrypt data.
No, reading bits from platters or the bus is a partial analysis of
the whole firmware question. It's already been suggested in links
how firmware can hook the user
Various wrote:
> > Which site blocks tor exit entirely?
On Wed, Mar 11, 2015 at 11:58 PM, Libertas wrote:
> The FreeBSD forums and (IIRC) download servers do the same thing, just
> dropping packets from Tor exits. Very annoying. I haven't got around to
> emailing them about it yet.
Found an exit
Is there some reason "freebsd.org" and all it's
subdomains don't immediately 302 over to
https foreverafter?
Same goes for use of svn, which has no native
signable hashed commit graph, as freebsd's
canonical repo... instead of git which does.
Not to mention the irreproducible builds / pkgs / ISO'
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.)
On Wed, Mar 8, 2017 at 10:52 AM, Dag-Erling Smørgrav wrote:
> grarpamp 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, an
> It is virtually impossible to guard against firmware rootkits because
> cpu cannot prevent the card's or device's cpu from from executing that code.
> This was made known by the malware embedded in disk drives' FW, and
> other peripherals' FW, such as wifi and graphics, to name a couple.
> It is
Over two years ago this "trojans in the firmware" was mentioned here.
These attacks are real and are in the wild. They are created and
used by various hats from adversary to researcher to miscreant...
and ultimately can end up passing unwittingly through degrees of
separation to and among you and
Blobs that fix exploitable things may be slightly better than blobs.
Awareness should be raised, and updates applied to systems.
# sysutils/devcpu-data New Microcode Released for Intel / AMD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219268
___
fr
Blobs that fix exploitable things may be slightly better than blobs.
Awareness should be raised, and updates applied to systems.
# sysutils/devcpu-data New Microcode Released for Intel / AMD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219268
___
fr
-- Forwarded message --
From: Shawn Webb
Date: Sun, Feb 25, 2018 at 5:17 PM
Subject: Re: [tor-relays] FreeBSD 11.1 ZFS Tor Image
To: tor-rel...@lists.torproject.org
On Sun, Feb 25, 2018 at 04:03:49PM -0600, Conrad Rockenhaus wrote:
> Wow, I didn't expect my friendly gesture to st
https://www.youtube.com/watch?v=bT_k06Xg-BE
Without exploit mitigations and with an insecure-by-default design,
writing malware for FreeBSD is a fun task, taking us back to 1999-era
Linux exploit authorship. Several members of FreeBSD's development
team have claimed that Capsicum, a capabilities/s
It's unfortunate that some repliers end up diminishing the benefits of the
perfectly legitimate means of distributing information, whereby involving and
cultivating concurrent discussion across potentially interested, mutually
beneficial, and or otherwise isolated / unaware groups that is "cross po
Packages are delivered via a single quarterly label here
https://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/
which corresponds to the latest quarterly branch label here
https://svnweb.freebsd.org/ports/branches/?sortby=date#dirlist
However, similar to how the tags here
https://svnweb.freebsd.
ng with the date, alternately: /prev_quarter
/this_quarter - same as today's /quarterly
/head - unlikely due to build / mirror times and other factors
/Qn - expose these for manual tracking and cutforward,
and the validation purposes below
[bcc for thread ref]
On Sun, Jul 22, 2018 at 4:44 AM,
https://zerodium.com/program.html
"the research becomes the exclusive property of ZERODIUM
and you are not allowed to re-sell, share, or report the research
to any other person or entity."
Opensource Unix Foundations should strongly consider
forming open collaborative crowdfunding and paying simi
https://zombieloadattack.com/
https://zombieloadattack.com/zombieload.pdf
https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html
https://github.com/IAIK/ZombieLoad
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018
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 l
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
>
On 6/18/19, grarpamp wrote:
> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> As it is not in the current .md, when was the issue
> discovered by Netflix / Looney?
One week has gone by, so asking again...
When was the issue discovered b
On 6/24/19, grarpamp wrote:
> On 6/18/19, grarpamp wrote:
>> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> As it is not in the current .md, when was the issue
>> discovered by Netflix / Looney?
>
> One week has gone b
>>> https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> 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 pa
Continued from beginnings in:
https://lists.freebsd.org/pipermail/freebsd-security/2019-June/009996.html
> I don't generally document a timeline of events from our side.
There would be benefit to further transparency with
some new data fields in FreeBSD advisories,
leading to metrics analysis by
On 7/5/19, Peter Jeremy wrote:
> On 2019-Jul-04 00:06:10 -0400, grarpamp wrote:
>>Continued from beginnings in:
>>https://lists.freebsd.org/pipermail/freebsd-security/2019-June/009996.html
> What benefits would be gained by
Some have been, and more can be by others,
outli
For consideration...
SVN really may not offer much in the way of native
internal self authenticating repo to cryptographic levels
of security against bitrot, transit corruption and repo ops,
external physical editing, have much signing options, etc.
Similar to blockchain and ZFS hash merkle-izatio
[broken links fixed]
For consideration...
SVN really may not offer much in the way of native
internal self authenticating repo to cryptographic levels
of security against bitrot, transit corruption and repo ops,
external physical editing, have much signing options, etc.
Similar to blockchain and
https://developer.amd.com/sev/
https://github.com/AMDESE/AMDSEV
https://arstechnica.com/gadgets/2019/08/a-detailed-look-at-amds-new-epyc-rome-7nm-server-cpus/
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
https://libvirt.org/kbase/laun
>> Just whose secure keys do you suggest? I go to a lot of trouble to disable
>> secure boot so I can load any operating system I want.
Some motherboards have BIOS that allows you to both
- Upload your own keys
- Delete all the spooky Microsoft keys
Read the UEFI Secure Boot specification documen
Although somewhat different from the virtualization part of the subject, both...
- AMD (Secure Memory Encryption, and Memory Guard) on
both EPYC and Ryzen Pro today
and
- Intel (Multi Key Total Memory Encryption) likely on Xeon
in the near future
... also do seem to have some OS dependant bits
On 10/4/19, Igor Mozolevsky wrote:
> On Fri, 20 Sep 2019 at 22:01, grarpamp wrote:
>>
>> For consideration...
>> https://lists.freebsd.org/pipermail/freebsd-security/2019-September/010099.html
>>
>> SVN really may not offer much in the way of native
>&g
For consideration...
SVN really may not offer much in the way of native
internal self authenticating repo to cryptographic levels
of security against bitrot, transit corruption and repo ops,
external physical editing, have much signing options, etc.
Similar to blockchain and ZFS hash merkle-izatio
>> would be really nice also to get UEFI BOOT compatible with SECURE BOOT
>> :-)
>
> Unless you are using your own BIOS, the above means getting Microsoft
> to sign boot1.efi or similar. Shims that simply work around lack of
> acceptible signature don't help.
As before in this thread, some motherb
People appear to be talking about using and
"authenticating / verifying" TLS certs now with at least
perhaps this NFS, and certainly with other apps.
If so, it's required critical thing for the admins and users to have
the option to pin the certificate pubkey fingerprints in four ways...
- Ignore
The underlying initializing 'git init' commit hash must be
signed by security officer key having sufficient human PGP-WoT.
Git also supports sha-256 soon now, adoption should
be researched from various online article series and
work product before committing plans...
https://lwn.net/Articles/82335
On 9/1/20, Shawn Webb wrote:
> I'm curious if there's any plans for read-only access over ssh.
> Trusting FreeBSD's ssh key material is likely easier than trusting
> HTTPS in certain regions.
A bit moot when such key materials of all services, and repos,
and ticketing, and reviews, and builds, an
> The underlying initializing 'git init' commit hash must be
> signed by security officer key having sufficient human PGP-WoT.
>
> Git also supports sha-256 soon now, adoption should
> be researched from various online article series and
> work product before committing plans...
> https://lwn.net/A
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/releases/12.2R/signatures.xml
Is it plan that 12.x 13.x etc continue with
provision of sig files for BETA and RC?
If so, process can be added to releng todo docs,
and the sig asc files pushed out to website,
and to download areas (https, f
> They will be added with the first RC build
Yes RC* seems the latest point in timeline
to begin excercise them.
> a bug in the order of operations
> And there is the PGP-signed email to stable@ that contains
> them.
Future noting that lists do not support foreknown path schemes
for that data.
>> > And there is the PGP-signed email to stable@ that contains
>> > them.
>>
>> Future noting that lists do not support foreknown path schemes
>> for that data. Whereas repo, website and dataset locations are more
>> predictable and programmatic... allowing fetching, validation, etc.
>
> And for R
> [src's] included on the
> installation medium for reproducibility
Wherever the src.tgz, they should not be considered to be
unbreakable reproducible bitwise duplicate authentic or
traceable back to any repo since there is no provable cryptographic
chain back to same, only assertions over the bre
> does anyone have an opinion on AMD's "Secure Memory Encryption"? This
> transparently encrypts all/most RAM pages.
> Looking at some tech docs, this seems fairly easy to implement.
> I was wondering if someone has attempted that already, or knows of
> reasons why not to.
Consider applications to
FYI...
Third party CA's are an untrusted automagical nightmare of global and
local MITM risk...
- CA's issuer gone wrong... Govt, Corp, Bribe, Rogue, Court, War,
Force Majeure, Crime, Hack, Spies, Lulz, etc.
- CA's store bundler gone wrong... Mozilla, Microsoft, Apple, BSD, etc
in same ways above.
Shouldn't this get a kernel option, sysctl, test app...?
https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf
AMD advised customers last week to disable a new
performance feature if they plan to use CPUs for sensitive operations,
as this feature is vulnerab
On 4/17/20, Ryan Moeller wrote:
>
>> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote:
>>
>> On 4/17/20 11:35 AM, Ryan Moeller wrote:
>>> OpenZFS brings many exciting features to FreeBSD, including:
>>> * native encryption
>> Is there a good doc reference on available for using this? I believe th
On 4/17/20, Ryan Moeller wrote:
>
>> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote:
>>
>> On 4/17/20 11:35 AM, Ryan Moeller wrote:
>>> OpenZFS brings many exciting features to FreeBSD, including:
>>> * native encryption
>> Is there a good doc reference on available for using this? I believe th
Generally speaking, surveying fieldwork of other OS, in whatever
areas of the OS, may be informative / comparative / useful.
Random number generator enhancements for Linux...
https://www.zx2c4.com/projects/linux-rng-5.17-5.18/
On 3/26/22, freebsd-li...@sensation.net.au
wrote:
> I think the best way to do it would be to call random_harvest_queue(...),
> but what do I use as the source enum (see /usr/include/sys/random.h)?
> ENTROPYSOURCE, I guess?
Try search for use of that function in the source, and
maybe look into ho
> Clearly, something has failed. The archives show no messages to...
Do they show up here...
rsync -nHaxi bit0.us-west.freebsd.org::FreeBSD-mailarchive/
That is supposed to be the ultimate raw history archive of
all freebsd mail since forever, or at least should be such
a sort of independent del
>> https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html
> Intel ... their never-ending failure to design or implement
https://www.forbes.com/sites/richardbehar/2016/05/11/inside-israe
On 7/12/22, mike tancsa wrote:
>> Just wondering how this might impact FreeBSD ?
>
> https://news.ycombinator.com/item?id=32071949
>
> https://comsec.ethz.ch/research/microarch/retbleed/
FreeBSD should keep a wiki table of all these
HW attacks with at least three columns...
- The exploit
- Were m
>> FreeBSD should keep a wiki table of all these
>> HW attacks with at least three columns...
>> - The exploit
>> - Were mitigations published [by hw vendors or sw communities]
>> - Were those or other [mitigations] applied [to freebsd]
On 7/13/22, John Gray wrote:
> Like this one?
> https://wiki
On 9/15/22, Dag-Erling Smørgrav wrote:
> I will be removing OPIE from the main branch within the next few days.
> It has long outlived its usefulness. Anyone still using it should look
> into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).
> https://reviews.freebsd.org/D36592
A
On 9/15/22, Dag-Erling Smørgrav wrote:
> Neither HOTP nor TOTP require dedicated devices.
> HOTP codes are sequential and can be pre-generated...
Those aren't really their intended or advertised usage models,
nor do common implementations support those modes.
Is FreeBSD contributing and supplying
> gives ... sense of ultimate control ... we are still the masters of the
> computer.
Tens of billions of gates on modern CPU's NIC's GPU's HDD's,
every single one of them a closed source hw black box,
same for thousands upon thousands of lines of firmware,
hundreds of undocumented opcodes some n
Generally, that ping has no end-to-end security (neither
does TLS if relying solely on the silly CA model), and that TLA's
[and Tier-n ISP's, VPN's, Tor's, WiFi's, etc] can all MITM at will,
and that everyone is a target of some one/entity these days... then
this is bad. Which if it applies to Micr
Again, FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or packages or wherever else.
Including such bundles exposes users worldwide to massive risks.
You need to do more gpg attestation, pubkey pinning [1], tofu, and
cert management starting from e
> On first run, BLAKE3 runs at the same speed as SHA-512.
> On my system, the second run is 17x faster.
> for hash in b3sum sha256sum sha512sum
> Executed in5.05 secs
> Executed in7.46 secs
> Executed in4.84 secs
> for hash in b3sum sha256sum sha512sum
> Executed in 280.16 millis
> E
https://www.freebsd.org/releases/12.4R/announce/
"
PGP-signed checksums for the release images are also available at:
https://www.FreeBSD.org/releases/12.4R/signatures/
A PGP-signed version of this announcement is available at:
https://www.FreeBSD.org/releases/12.4R/announce.asc
"
However
>> looks like the "make delete-old-libs" has deleted that lib pam_opie.so.6
>> and now I cannot pass the login prompt
>> says the error "pam_opie.so: not found
>> how can I get it back? I tried everything and nothing brought it back
> commit 0aa2700123e22c2b0a977375e087dc2759b8e980
> Differential
On 1/5/23, Graham Perrin wrote:
> I recall the original email
Orthagonal as it, and some notes since neither consider any
potential gap issue or/of any perhaps whimful removal process,
nor moves forward on any of potential better alternatives to that
which were hint (port) a bit in posts even bef
On 1/6/23, Xin Li wrote:
> Security team has discussed this a decade ago. See
> https://www.miknet.net/security/skey-dungeon-attack/
> for technical details.
That would mean that FreeBSD knowingly left users exploitable without
doing even the "easy fix" in that article to the opie code for over
> /usr/share/certs
Was never necessary.
Should not have been added.
>> trust store
> list of trusted CAs
People are fools if they think they can "trust" any of those.
Including a live cert store in base does little but endorse exposure
of users to such external risks. Users before at least had t
Did anyone check if -j/-J might have similar edge cases?
On 2/15/23, Mel Pilgrim wrote:
> # echo -n | geli attach -C -p -k - gpt/zdata15
> geli: Wrong key for gpt/zdata15.
> geli: There was an error with at least one provider.
That test failed so the "empty" or "NULL" key (aka "echo -n")
is not the key. These should not work either
printf '' | geli
pr
On 7/27/23, Olivier Certner wrote:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=0bc3126c9cfa0b8c761483215c25382f831a7c6f
That commit is labeled for 17h (z1/z1+/z2).
The one below was made less than one day prior for 19h (z3/z3+/z4),
so it likely contai
> Updating the CPU microcode _after_ the kernel has started
Kernel does lot of stuff "after it starts" running,
after it gets loaded, before userland, so really
your note means next possible place to "updating"
is after kernel hands off to init.
> seems questionable.
Yes it's supposed to go in f
On 8/22/23, i...@tutanota.com wrote:
> There seems to be a bit of open (and rather old) ZFS native encryption
> bugs which still haven't been fixed and it doesn't look like it is
> something that is being working on.
>
> Last night I was going to move some important files from an unencrypted
> dat
80 matches
Mail list logo
