Malloc -Z
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 default malloc? Bonus: What would be needed to make the useful streams: /dev/one /dev/10 /dev/01 In addition to /dev/zero. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Malloc -Z
> 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 "memory from malloc(3) is not > guaranteed to be zeroed." by specifically setting it to non-zero. Hmm, well for debugging/fuzzing programs, Z or J could be useful. As would new R(random), 5(0x55), a(0xaa), and f(0xff) variations. But for security, it seems running with any of them set would be wise or flat out required. No? As in the case where users are untrusted (mischievous, but unable to gain root). Because while your own shiny new program may zero on free, all the other installed programs that handle 'sensitive' data may not. And without using say, Z... any user could scrape the box. Right? ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
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 cryptographic authentication. Any of hundreds of committer and admin accounts could be compromised with the attacker silently editing the repo. The same applies to any of those accounts going rogue. Backtrack diffing from a breach to 'see what changed' is not the ideal option. You really need to be using a strong repo so that any attack on it is null from the start. Another problem is bit rot wherever it may occur... disk, hardware, the wire, EMP and other systems. As it is now, we have no way to verify that what we get on pressed CD's, ISO's, FTP sites, torrents, etc is strongly linked back to the original repo. Signing over a hash of the ISO is *not* the same as including the strong repo hash (commit) that was used to build the release and then signing over that and the ISO. We can't know that our local repository updates match the master. ports.tar.gz has no authentication either. Nor does anything in the entire project that originates from the current SVN/CVS repo... webpages, docs, tools, source tarballs, etc. The FTP packages aren't signed, and there are weak MD5's used in various parts of the install/package tools, mirrors, etc. We can't trade hashes amongst people. It's all just a bunch of random bits that someone may or may not have signed over. And even if signed they still wouldn't be strongly linked back to the master repo. Having such a disconnect at the root of everything you do is simply not good practice these days. And these days, Git is what people and projects are moving to, and its rate of adoption and prevalence have essentially won out over all the rest in the new 'revision control 2.0 world'. And knowing Git is now more or less essential if you want to participate in a wide variety of community development, ref: github, etc. The FreeBSD project needs to be providing both itself, and its users and benefactors with verifiable assurance that its repository, and any copies and derived products, are authentic and intact. Don't argue against such a repository feature, or the cost to move, or bury your head in the sand by saying it could never happen to us... Take this as a real opportunity to lead amongst the major opensource projects like Linux, and among the BSD's (like DragonFly has), and move to Git. Once the root is fixed, you can push out secure distribution and update models from there. It all starts at the root and can't be done without it. https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html Verifies the connectivity and validity of the objects in the database http://git-scm.com/about/info-assurance The data model that Git uses ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It's impossible to get anything out of Git other than the exact bits you put in. It is also impossible to change any file, date, commit message, or any other data in a Git repository without changing the IDs of everything after it. This means that if you have a commit ID, you can be assured not only that your project is exactly the same as when it was committed, but that nothing in its history was changed. https://en.wikipedia.org/wiki/Git_(software) The Git history is stored in such a way that the id of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. The structure is similar to a hash tree, but with additional data at the nodes as well as the leaves. Some references... http://git-scm.com/ https://github.com/ http://gitweb.dragonflybsd.org/dragonfly.git https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
FreeBSD crypto and security meta [was: zfs review 4185 New hash algo]
> 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: >> http://cr.illumos.org/~webrev/skiselkov/new_hashes/ >> >> This webrev implements new hash algorithms for ZFS with much improved >> performance. There are three algorithms included: > [...] > > Personally I'd love to have an option to use HMAC/SHA256 for example > with secret key stored in pool. Currently in our product we put ZFS with > SHA256 on top of block-level disk encryption. I'd feel much better to > have proper data authentication using HMAC. At some point I may find > time to implement that based on your patch. With recent news renewing broad interest in self/peer examining the security of the entire spectrum of products... has the FreeBSD implementation of GELI/crypto/random published design papers, presentations and reviews? Are these collected centrally for easy reference by the community? Quick ref: https://www.freebsd.org/cgi/man.cgi?query=geli https://www.freebsd.org/cgi/man.cgi?query=crypto&sektion=9 https://www.freebsd.org/cgi/man.cgi?query=crypto&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=rndtest&sektion=4 Further, and more generally on the higher level meta topics we've seen... How is FreeBSD working with the community regarding possible updates to cipher suites, embedded crypto libraries, and the like? Similarly, how is it approaching the movement towards end-to-end toolchain integrity... from the repository, through deterministic builds, and on out to secure distribution and updates? This should be viewed not as a pointer but 'While we're on the topic, hey, how are the FreeBSD folks doing' :) Presumably this subthread could migrate to freebsd lists for those interested in following the details more closely. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
FreeBSD crypto and security meta
> 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) ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Secure Infrastructure [Crypto signed ISO images]
>>> 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 ISO's [hashes of same] is a common practice. As is now signing the packages. However, just remember that both of these are only handwavy security bandaids trying to be placed from the periphery in, which is not the way to do things right... Until the FreeBSD project ... (1) moves to a repository such as Git [or something like the even further crypto integrated Monotone], where the repository itself has an internal crypto hash structure that can be signed from the very first initializing commit and upon later commits/tags/branches, etc... and (2) has and uses deterministic reproducible builds for everything flowing downstream from that [the source repo, packages, isos, build servers, rsync/ftp/http distribution servers, web/wiki/forum/mail servers, etc...] ... signing the periphery may look good to the casual observer, but it is ultimately untraceable in any cryptographic sense to the code from which those periphery elements are purported to come from. That's not a good position to be in, and is a clarification regarding discontiguous trust chains that needs pointed out. It also wouldn't hurt to have the repo on ZFS raidzN sha256, ECC ram, etc... if not already. >> if you verified the certificate of https host... ... you probably have more to learn about verification. https://www.eff.org/observatory https://en.wikipedia.org/wiki/Certificate_transparency And let's not forget the needed DNSSEC and IPSEC components. Though 1 and 2 above would be a great start. References... https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details https://wiki.debian.org/ReproducibleBuilds https://gitian.org/ http://git-scm.com/about/distributed http://git-scm.com/about/info-assurance http://www.monotone.ca/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Fwd: [Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?)
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: cryptogra...@metzdowd.com Hi Perry, Sorry for the very slow reply; I was away on vacation. On Fri, Jun 20, 2014 at 9:04 AM, Perry E. Metzger wrote: > > On Thu, 19 Jun 2014 23:37:04 -0400 Darren Lasko > wrote: > > On Thu, Jun 19, 2014 at 5:06 PM, Perry E. Metzger > > wrote: > > > > > It is different in a vital respect -- in the software > > > implementation, you can more or less check that everything is > > > working as expected, and you don't have to trust that the drive > > > isn't sabotaging you. That's quite different -- vitally so, I > > > think. > [...] > > However, to your point that "in the software implementation, you > > can more or less check that everything is working as expected," > > this only holds true if it's open-source (and as we have found > > recently, this is still no guarantee against nasty security > > "flaws"), or if you're willing to reverse-engineer a closed-source > > product (which you could also do with a hardware-based product, > > though likely at a greater expense). > > No. You are missing a very vital point. > I really don't think I missed your point. I even acknowledged that point in my previous post. My counter-point is merely that the actual media encryption part, while vitally important, is only a small part of the overall FDE solution. The other parts of the solution are equally important, much harder to get right, and not readily verifiable in *either* a hardware solution or a closed-source software solution. I would argue that if you don't trust hard drives with built-in encryption, then you also shouldn't trust closed-source software drive encryption products (and maybe you don't). In fact, even the actual media encryption part is probably much harder to verify in a closed-source software implementation than you might be thinking... > If the sectors on the drive are encrypted with some particular > algorithm using some particular key, I can check, in a software only > solution, that the sectors are indeed encrypted in that key using > that algorithm. Getting "that key" out of a closed-source software FDE product will require reverse-engineering the product or employing something like the techniques used in the Princeton "cold boot attack". And once you have the key, you also need to know the encryption algorithm and cipher mode being used (which is usually specified in the product documentation) *plus* the product's algorithm for generating IVs/tweaks for the cipher mode (probably only discoverable by reverse-engineering, since I've never seen a closed-source implementation give this level of detail in its documentation). This is why I said in my previous post, "you can take a look at the ciphertext and verify that you see random-looking bits, and maybe verify through experimentation that it's not using a poor choice of cipher mode like ECB." Anything more than that will require you to dive deep into the inner workings of the product. [...] > > It is actually much worse than that since the hardware implementation > could be doing things like stashing keys in hidden sectors, but one > need not go so far as to worry about that because even the most basic > audit is impossible. > Software-only products are capable of implementing equivalent levels of malfeasance, for example by obfuscating the plaintext media encryption key and stashing it in the area of the drive they reserve for their pre-boot code and metadata. They could even encrypt the media key using a public key to which the developers (or their "partners") hold the private key. > > > While it's true that even with a closed-source product you can take > > a look at the ciphertext and verify that you see random-looking > > bits, > > No, if they say "this is using AES-256 GCM" I can do more than that. > Again, not without the key. > > If your closed source vendor is not telling you what algorithm and > mode they are using, they are of course also doing something > unacceptable and should be excluded from your purchases. It is > acceptable (though not even remotely optimal) if the encryption > implementation is closed source, but it is utterly unacceptable if > its method of operation is not fully disclosed. > Your original comment was about "checking/verifying", not "disclosure". If you look at the datasheets for self-encrypting drives from just about any respectable manufacturer, they disclose the encryption algorithm/mode: http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-series-sata-specification.pdf (XTS-AES-256, FIPS 197 certified) http://www.micron.com/-/media/documents/products/data%20sheet/ssd/m550_2_5_ssd.pdf (AES-256 CBC) Seagate has FIPS 1
Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network)
On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before 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 globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720 ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: [Cryptography] trojans in the firmware
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 help or hinder. > > The VM is sitting where the man in the middle wants to be and if it wants > can protect or expose > the OSs that it hosts. A VM can protect a hard drive from being infected > by blocking vendor > codes that might try to update or corrupt modern disks of boot flash memory. 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 hardware vendors to roll out signature verification in hardware, is to simply kernel block all commands unnecessary to actual production use of the disk. Permit only from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. Thus every other command component, including firmware update, vendor specific, and binary fuzzing, gets dropped and logged. It could be done as a securelevel, or compiled in. It's definitely not bulletproof, but it does force adversaries to add that much more exploit code and effort to get root and go around the driver interface to access the hardware directly. Defense in depth. Similar tactics could be applied to other areas where firmware and vendor/fuzzable opcodes are involved... usb, bios and cpu. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: [Cryptography] trojans in the firmware
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 hardware vendors to roll out signature >>verification in hardware, is to simply kernel block all commands >>unnecessary to actual production use of the disk. Permit only >>from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. >>Thus every other command component, including firmware update, >>vendor specific, and binary fuzzing, gets dropped and logged. > > If the disk drive or flash drive firmware has already > been compromised, none of this will work, because the firmware > simply waits for the appropriate "legitimate" read & write > commands, and does its thing. Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to kernel path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). > BTW, what happens with "emulated" disks -- e.g., .vdi files -- > in vm's ? Presumably these emulated disks have no firmware to > update, so any attempt would either be ignored or crash the > system. Depends on how the vm is coded. My guess is vm's that emulate say disk devices, munge those opcodes too. Yes, looking at how virtualbox and even lightweight instances like jails code/handle it could be useful. Try it and see :) In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised, and defense in depth. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: [Cryptography] trojans in the firmware
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 other exploits. Multiple defenses are always useful.. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: [Cryptography] trojans in the firmware
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 no cost to performance extra freebie underneath that. However since the raw device interface is still accessible, neither of them do anything to block firmware updates. > Karl Denninger saith: > 1. The BIOS (which reads the boot sector) has not been compromised. > 2. Once the drive code has been tampered with These cases were addressed earlier... " Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to firmware path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised. " > how many of these attacks are going to be loaded into your machine > through a _*running*_ modern BSD-style system? These for starters, then all the public hacker malware versions of the same thing both extant and coming... https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg http://25zbkz3k00wn2tp5092n6di7b5k.wpengine.netdna-cdn.com/files/2015/02/Equation_group_questions_and_answers.pdf > I suspect the answer is > "few" and a false sense of security is worse than none at all. Defense in depth is not a false defense, even when thrown at the few. Given a clean system, the ability to block these opcodes would seem defensive. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
trojans in the firmware
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 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 no cost to performance extra freebie >> underneath that. However since the raw device interface is still >> accessible, neither of them do anything to block firmware >> updates. > what has blocking firmware updates to do with > firmware being able to read the data passing > through the controller ? Reread the entire thread and all the linked materials. If your drive is clean and you kernel block the malicious firmware update command, the exploit fails and your drive remains clean. If you don't block it, then your drive gets rooted and then yes, there's nothing you can do after that. And since users don't have JTAG gear/skills and device vendors usually never publish a firmware update anyway, you can't verify or securely reflash even if you did discover it got rooted. Thus you now own a worthless brick with a warranty that won't be honored. > That encryption is a good line of defense, you can > read here: > https://www.ibr.cs.tu-bs.de/users/kurmus/papers/acsac13.pdf > in section 4.1. No hardware and software disk encryption themselves don't prevent installation of the firmware, nor help much afterwards given the current as yet non-ideal state of the entire system protection/crypto ecosystem. The MBR, boot, loader and whatever other early stages, are not encrypted or signed... malicious firmware can exploit that. It could also use DMA to read/write RAM to get your FDE keys and so on. Even SecureBoot with FDE doesn't help there. It's all caveated in the doc. To be more secure you need to disallow the malicious firmware update from taking place to begin with. The standard interface for that is through the /dev device provided by the disk driver over the bus subsystem. Block/filter out all non-production opcodes from those interfaces and and it becomes more work for kids to exploit. Add that to other defenses in depth and you're better off. Long term, you should demand the vendors include a $0.10 hardware read-only update jumper and a signed authority root anchored in the mask ROM. You should demand the t10/t11/t13/serialata standards bodies include a readout command for firmware verification and backup. For that matter, you should demand vendors include another jumper for pointing to your own installable ROM space in flash (or via pin header) and to also open up their specs so you don't have to use their literally stupid and broken firmware blobs [1]. How many tens of thousands of users strong are you BSD? How many tens of thousands of users strong is Linux? Yet all of you combined can't seem to place even two calls/mails per month to each vendor asking for these things... shame. You can and should be overloading their switchboards... they'd drop to their knees before your armies in a week. [1] Vendor code is generally buggy crap quality, quite often highly guarded just to save embarassement there, to dodge responsibility for making fixes by saying "what bugs, where", and to speed up obsolesense. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Fwd: [Cryptography] trojans in the firmware
> 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 function. Kernel options to permit only your approved list of opcodes and block all else by default would seem useful to have. > http://www.spiegel.de/media/media-35661.pdf Again, look at the list of Unix operating systems and file systems. These guys are calling Unix out by name, and soon the common script kid will be too. Unix is under attack and this stuff can't be ignored as "too rare and/or hard and/or low market share to be relavent" anymore. -- Forwarded message -- Date: Mon, Feb 23, 2015 at 12:10 PM Subject: Re: [Cryptography] trojans in the firmware FYI -- CMU has been hacking disk drive firmware since the 1990's for "smart disks" and "performance"; UCSD has been hacking flash drive firmware more recently. I believe that DARPA has also openly solicited for disk drive/flash drive firmware hacking capabilities. Both CMU & UCSD are hotbeds of NSA recruitment activity. We now know that in NSA parlance "smart" anything = "spying" anything; e.g., "smart disks" = "spying disks"; "smart phones" = "spying phones", etc. BTW, hiding stuff in a flash memory stick is even easier than in a hard drive. This is because flash memory is so unreliable, that there is typically a huge percentage of unused space; the cheaper the flash memory, the smaller the fraction of usable reliable memory space. So it wouldn't be at all surprising to find that your 32GB flash drive is really constructed from 64GB chips, and that 50% of the device is unavailable for use. It is highly unlikely that _all_ of this unused space is unreliable, so this leaves plenty of room for NSA lurking. But even if the device were 100% reliable, noticing that only 50% was actually in use would be unremarkable, given the typical degree of unreliability of these types of devices. For these reasons, it is critical for flash memory devices to _open up_ their API's, so that the raw memory (with all of its warts) can be inspected and verified. http://www.wired.com/2015/02/nsa-firmware-hacking/ How the NSA’s Firmware Hacking Works and Why It’s So Unsettling By Kim Zetter 02.22.15 8:09 pm One of the most shocking parts of the recently discovered spying network Equation Group is its mysterious module designed to reprogram or reflash a computer hard drive’s firmware with malicious code. The Kaspersky researchers who uncovered this said its ability to subvert hard drive firmware—-the guts of any computer—-“surpasses anything else” they had ever seen. The hacking tool, believed to be a product of the NSA, is significant because subverting the firmware gives the attackers God-like control of the system in a way that is stealthy and persistent even through software updates. The module, named “nls_933w.dll”, is the first of its kind found in the wild and is used with both the EquationDrug and GrayFish spy platforms Kaspersky uncovered. It also has another capability: to create invisible storage space on the hard drive to hide data stolen from the system so the attackers can retrieve it later. This lets spies like the Equation Group bypass disk encryption by secreting documents they want to seize in areas that don’t get encrypted. Kaspersky has so far uncovered 500 victims of the Equation Group, but only five of these had the firmware-flashing module on their systems. The flasher module is likely reserved for significant systems that present special surveillance challenges. Costin Raiu, director of Kaspersky’s Global Research and Analysis Team, believes these are high-value computers that are not connected to the internet and are protected with disk encryption. Here’s what we know about the firmware-flashing module. How It Works Hard drive disks have a controller, essentially a mini-computer, that includes a memory chip or flash ROM where the firmware code for operating the hard drive resides. When a machine is infected with EquationDrug or GrayFish, the firmware flasher module gets deposited onto the system and reaches out to a command server to obtain payload code that it then flashes to the firmware, replacing the existing firmware with a malicious one. The researchers uncovered two versions of the flasher module: one that appears to have been compiled in 2010 and is used with EquatinoDrug and one with a 2013 compilation date that is used with GrayFish. The Trojanized firmware lets attackers stay on the system even through software updates. If a victim, thinking his or her computer is infected, wipes the computer’s operating system and reinstalls it to eliminate any malicious code, the malicious firmware code remains untouched. It can then reach out to the command server to restore all of the other malicious components that g
Re: [Cryptography] trojans in the firmware
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 users unencrypted boot binaries through to the users kernel. For that matter, a modified boot chain could be stored in the service area. A user would have to use SecureBoot, TPM, IOMMU, TXT, GELI and perhaps other things, all of them properly, having no holes, together, right now, at least three of which they are unlikely to have ubiquitous access to until a couple hardware generations or personal refresh cycles into the future. An ideal full solution for which is yet to come. Not to mention needing to install it all cleanly (from BTW, an install image which has no reproducible build and no cryptographic chain back to the insecure unsigned source repo anyways). But yeah, let's talk circular instead of about possible actually coding defense in depth such as maybe blocking the most common easiest path a malicious opcode will likely take to irrepairably infect clean hardware in the first place... through the drivers ... > There is no threat to freebsd ... because at least Unix is said to be immune to threat... http://www.freebsd.org/security/advisories.html http://www.openbsd.org/errata56.html http://web.nvd.nist.gov/view/vuln/search-results?query=linux+kernel&search_type=last3years&cves=on > Weaknesses of this measure are remote and highly costly for the > attacker. If one is such a person of interest It's already been talked how this tech will be integrated into everyday run of the mill malware. And how users will be subject to infected drives via second purchase, inheritance (both from other people and from other operating systems), use of hosting services, trading, booting CD's, etc. Persistant malware in users boot chains is nasty, users don't have to be of interest or be targeted, the code doesn't care, grandma's surfbox could get it. Please learn to email... trim the original to the minimum needed for context, reply inline below, and stop copying 400 line digests with meaningless digest subject lines out to everyone on the list. On whenever, someone else wrote: > Since the chip holding the firmware has > leads through which it is loaded with the firmware, > is it not possible to disable or burn (with laser) or cut > just the leads through which the chip is WRITTEN to > (in order to re-program it)? Depends on the design. The hacking links or docs from the drive/chip vendors would be more helpful there. ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
FreeBSD forums, etc [was: Protest Blocking Tor via CloudFlare]
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 that works forums and mapped it for weeks now, but that's a real pain for normal Tor users to contemplate doing. Yes, it's quite annoying and one would hope mailing them to achieve at least readonly access would be opened up. Why block disemmination and viewing of simple free knowledge? This may be inadvertant lack of in depth and open thought on things. This should hopefully get further thought going. They also need to make their builds deterministic and crypto traceable back to a crypto secure source repo which SVN is not afaict. But that's a whole other topic, and these days an important one to raise and ensure is addressed. After all, spies, moles, exploit[er]s, and bitrot are everywhere. Relavent link hierarchies... https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details http://en.wikipedia.org/wiki/Comparison_of_revision_control_software http://git-scm.com/about/distributed http://git-scm.com/about/info-assurance http://www.monotone.ca/ ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
HTTPS on freebsd.org, git, reproducible builds
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's. These days these flaws are more than a bit ridiculous, especially for an OS, which by definition [excepting the hardware] should be your root of trust. Can we get a wiki project page and some traction on this? Thanks. ___ 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"
WikiLeaks CIA Exploits: FreeBSD References Within
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. ___ 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: WikiLeaks CIA Exploits: FreeBSD References Within
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, 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.) ___ 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: Filtering Against Persistent Firmware Rootkits - BadUSB, HDDHack, UEFI
> 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 possible for such device FW to insert malware into, > or modify, the RAM resident OS. > Apparently making OS's executable segments "non-writeable" can be gotten > around. There are two very different write directions involved... HW -> OS / SW ... Yes, as above, you're screwed. SW -> OS -> HW ... However, as before, you can add kernel filters to further help prevent software from writing the screwed firmware to your hardware in the first place. ___ 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: Filtering Against Persistent Firmware Rootkits - BadUSB, HDDHack, UEFI
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 your peers over daily sharing and other physical transactions, use of unaudited application and systems code, dual booting, parking lot attacks, computer labs, libraries, component swapping, etc. Some mitigation may be possible through kernel filtering modes... - Filter and log all known firmware / bios writing opcodes. - Filter and log all opcodes except those required for daily use, such as: read, write, erase unit, inquiry, reset, etc. - Filter and log all opcodes execpt those in some user defined rulesets. Default permit / deny, the usual schemes. In a securelevel, this may provide some resistance and extra steps of defense in depth to attacks that presume they have direct access to firmware without needing to smash the kernel further beyond root (also, root access is foolishly yet often available to users). FreeBSD should consider addressing any oppurtunities to further inhibit these attack vectors. Details via links below. (CC'd to a few lists to promote general awareness. Replies are perhaps best made only to freebsd-security@ . This post is what people were replying to but never made it.) # CAM - hdd, tape, optical, etc https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://spritesmods.com/?art=hddhack http://s3.eurecom.fr/~zaddach/ https://www.ibr.cs.tu-bs.de/users/kurmus/ https://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-part-1.html https://www.malwaretech.com/2015/06/hard-disk-firmware-rootkit-surviving.html http://web.archive.org/web/20150615181236/http://malwaretech.net/MTSBK.pdf https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/ http://web.archive.org/web/20130228090611/http://www.recover.co.il/SA-cover/SA-cover.pdf http://www.spiegel.de/media/media-35661.pdf # USB https://opensource.srlabs.de/projects/badusb https://github.com/robertfisk/USG/wiki # BIOS, UEFI http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/ http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/ # CPU http://inertiawar.com/microcode/ https://wiki.archlinux.org/index.php/microcode http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf https://en.wikipedia.org/wiki/Intel_Active_Management_Technology # FreeBSD, UFS - supported https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg # various https://en.wikipedia.org/wiki/NSA_ANT_catalog https://firmwaresecurity.com/ ___ 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"
Intel / AMD CPU Microcode Updates Required For Security
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 ___ 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"
Intel / AMD CPU Microcode Updates Required For Security
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 ___ 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"
Fwd: [tor-relays] FreeBSD 11.1 ZFS Tor Image
-- 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 start another debate, but the > reasoning behind offering this image was mainly for people who were operating > on OpenStack clouds who wanted to upload the image to their infrastructure > using glance and start things up quickly. I'm more than willing to provide the > ansible scripts I use to initially spin things up, once I clean things up > since there's still some manual things that can be automated. > > I'll just consider this idea dead in the water. That being said: > > On Sunday, February 25, 2018 3:50:44 PM CST Shawn Webb wrote: > > On Sun, Feb 25, 2018 at 09:05:00PM +, George wrote: > > > Conrad Rockenhaus: > > > > Hello All, > > > > > > > > If anyone is interested, I have a RAW image of a FreeBSD 11.1 ZFS image > > > > that is fully configured and ready to run Tor. Right now it's an eight > > > > GB image, but I'm reducing the size by removing all of the extra stuff > > > > on it from the upgrade from FreeBSD 11 to 11.1. > > > > > > I think it's great to ease the implementation of Tor relays, > > > particularly on BSDs. > > > > > > However, I'd be wary of an image that I didn't build myself, personally. > > > > I agree with that sentiment. I would rather Tor relay operators set up > > their systems themselves so that they know how that system is > > configured. > > > > I would also suggest users run operating systems that specialize in > > security, like OpenBSD or HardenedBSD. Running Tor on FreeBSD opens > > the door to mass exploitation via copy and paste style exploits. I > > would caution against such setups. Tor has a very unique threat > > landscape and the security of the relay should be of upmost > > importance. > > I'll be honest, I have never heard of a copy and paste style exploit. What is > it? Could you provide me a link with info about it, because I run several > FreeBSD instances and if I have a ticking timebomb on my hands, I need to fix > it. With FreeBSD's complete lack of exploit mitigations, all tor instances running on like FreeBSD systems can be exploited the same way. The memory layout is predictable, memory mappings can be writable and executable, etc. The virtual memory layout of tor on your FreeBSD 11.1-RELEASE-p6 instance is going to be the exact same as John Smith's instance. This means that attackers can write their exploits with 100% reliability, even with virtual memory addresses hardcoded. There's no need for ROP, JOP, SROP, etc. on FreeBSD. FreeBSD is literally stuck in 1999-era security. Writing exploits for such systems is extremely easy for today's offensive security researchers. FreeBSD really needs ASLR and W^X, at a minimum, for me to put even the slightest trust in for applications that are security-sensitive (like tor). Until then, I'd encourage Tor relay operators to make use of operating systems that put a focus on security, like OpenBSD or HardenedBSD. Just yesterday, I was notified of yet another FreeBSD box getting popped by an offensive security researcher. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE ___ tor-relays mailing list tor-rel...@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: PGP signature ___ 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"
Exploit Lecture: Writing FreeBSD Malware
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/sandboxing framework, prevents exploitation of applications. Our in-depth analysis of the topics below will show that in order to be effective, applying Capsicum to existing complex codebases lends itself to wrapper-style sandboxing. Wrapper-style sandbox is a technique whereby privileged operations get wrapped and passed to a segregated process, which performs the operation on behalf of the capsicumized process. With a new libhijack payload, we will demonstrate that wrapper-style sandboxing requires ASLR and CFI for effectiveness. FreeBSD supports neither ASLR nor CFI. Tying into the wrapper-style Capsicum defeat, we'll talk about advances being made with libhijack, a tool announced at Thotcon 0x4. The payload developed in the Capsicum discussion will be used with libhijack, thus making it easy to extend. We will also learn the Mandatory Access Control (MAC) framework in FreeBSD. The MAC framework places hooks into several key places in the kernel. We'll learn how to abuse the MAC framework for writing efficient rootkits. Attendees of this presentation should walk away with the knowledge to skillfully and artfully write offensive code targeting both the FreeBSD userland and the kernel. https://twitter.com/lattera/status/989602709950029824 Shawn Webb is a cofounder of HardenedBSD, a hardened downstream distribution of FreeBSD. With over a decade in infosec, he dabbles in both the offensive and defensive aspects of the industry. On the advisory board for Emerald Onion, Shawn believes in a more free and open Internet. His whole house is wired for Tor. Getting on the Tor network is only a network jack away! https://www.youtube.com/user/CarolinaConVideos/videos CarolinaCon was started in 2005 and has been held every year since. With each passing year the conference continues to grow and attract more attendees and speakers. As has always been the case, CarolinaCon is put together and run by an all-volunteer staff. CarolinaCon is proudly brought to you by "The CarolinaCon Group". The CarolinaCon Group is a non-profit organization registered in the state of NC, dedicated to educating the local and global communities about technology, information/network/computer security, and information rights. The CarolinaCon Group is also closely associated with various 2600 chapters across NC, SC, TN, VA, LA, DC, GA, PA and NY. Many of the volunteers who help develop and deliver CarolinaCon come from those chapters. ___ 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: Exploit Lecture: Writing FreeBSD Malware
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 posting", through their comments or failure to trim addressees should their future conversation subthreads narrow to within their more usual areas. Nor is it necessarily what any particular OP may or may not find interesting or represented from time to time of their own posts, but what comes from community analysis and any application of whatever the post subject matter may be to the betterment of FreeBSD. There's yet been no discussion in thread of the subject matter itself. Yes people's inclination should be to that, rather than to the latest fashion trends :) ___ 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"
Archives of last quarterly package builds?
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.org/ports/tags/?sortby=date#dirlist are archived here https://pkg.freebsd.org/FreeBSD:11:amd64/ as these https://pkg.freebsd.org/FreeBSD:11:amd64/release_[n] The last "ie: final" builds of each quarterly branch before they roll over should also be moved off into their own archived quarterly directories as https://pkg.freebsd.org/FreeBSD:11:amd64/Q[n] For example /quarterly/ should be repointed from 2018Q2 to 2018Q3, leaving 2018Q2 as a live "pkg" accessible archive. Eventually all such archives could be moved to historical archive server under typical release support expiry periods. This would also serve critical purpose as an independant original remote repository for validating local package / file signatures against compromise, corruption, loss. For example, does the last 2018Q2 (or older ones) still exist anywhere for users to reference and use? ___ 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: Archives of last quarterly package builds?
> I've asked for this but the answer is
> "no we don't do that.. and have no plans to".
What is the rationale? Or is another model of pkg build,
distribution, and archiving coming?
It seems no more would be needed than
- an update to release / handbook / mirror info noting their status
as "final, to be removed [to archives] on date + timeframe", say 1 year.
- simple sysadmin on pkg / web side as part of each quarter activity.
- some storage space.
- obviously they are the final builds of the branch, thus frozen.
Anything else / prereqs missing to doing that?
In addition to the earlier reasons...
'packages /latest' trails 'repo HEAD' so it's a fairly linear turnover.
Yet /quarterly gets a massive bump when the branches swap out
from underneath it.
So one could also see where enterprise and other pkg users might
be expecting a similar progression in /quarterly, and to manually
cutforward, not automatic large whack at once. Those production
bumps can hurt. So they might choose to track repo_conf /Qn
and trial the new quarter before moving to it.
It just seems that the final builds on those quarterly branches
should be left online for a while, instead of just ...poof...GONE.
ie: with pkg, this should work for a year or so...
/.../repo_conf: url: "pkg+https://pkg.FreeBSD.org/${ABI}/2018Q2";
Some labels could also be added for use in pkg's repo_conf...
/last_quarter - simpler than dealing 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, Julian Elischer wrote:
> On 22/7/18 5:59 am, grarpamp wrote:
>>
>> 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.org/ports/tags/?sortby=date#dirlist
>>
>> are archived here
>>
>> https://pkg.freebsd.org/FreeBSD:11:amd64/
>> as these
>> https://pkg.freebsd.org/FreeBSD:11:amd64/release_[n]
>>
>>
>> The last "ie: final" builds of each quarterly branch before they
>> roll over should also be moved off into their own archived
>> quarterly directories as
>
>
> I've asked for this but the answer is "no we don't do that.. and have no
> plans to".
> Which is a putty as it means you need to make your own snapshots if you want
> to have any reproducability.
> It no linger matters to me as we now roll all our own packages from source
> (we have private OS changes
> that make this a requirement), but it was a sore point for many years.
>
>
>>
>> https://pkg.freebsd.org/FreeBSD:11:amd64/Q[n]
>>
>> For example /quarterly/ should be repointed from 2018Q2
>> to 2018Q3, leaving 2018Q2 as a live "pkg" accessible archive.
>>
>>
>> Eventually all such archives could be moved to historical
>> archive server under typical release support expiry periods.
>>
>>
>> This would also serve critical purpose as an independant
>> original remote repository for validating local package / file
>> signatures against compromise, corruption, loss.
>>
>>
>> For example, does the last 2018Q2 (or older ones) still exist
>> anywhere for users to reference and use?
>
> no.
___
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"
BSD and Linux so easy to exploit that Zerodium pays just $50k for uid0
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 similar to openly acquire and fix exploits thus keeping them from going into secret blackholes which are often used directly against their very own users requiring, and in, security sensitive environments (be they corp, gov, personal, edu, ngo, biz, research, journalism, etc...), reducing continued exploitation of the work, users, and infrastructures of Opensource Unix OS projects through using bounties to identify improving production, review, security, audit, coding, feedback models in same. "Many ... have bug bounty programs for those who want the exploit used for defensive purposes, ie fixed... but they pay orders of magnitude less. *This is a problem.*" -- Bruce Reassert and 0wn the problem. ___ 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"
ZombieLoad Attack: Intel Exploits You... Again!
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-12130 https://www.youtube.com/watch?v=wQvgyChrk_g FreeBSD people... See linux patches in and update your microcode, ports, etc. ZombieLoad Attack Watch out! Your processor resurrects your private browsing-history and other sensitive data. After Meltdown, Spectre, and Foreshadow, we discovered more critical vulnerabilities in modern processors. The ZombieLoad attack allows stealing sensitive data and keys while the computer accesses them. While programs normally only see their own data, a malicious program can exploit the fill buffers to get hold of secrets currently processed by other running programs. These secrets can be user-level secrets, such as browser history, website content, user keys, and passwords, or system-level secrets, such as disk encryption keys. The attack does not only work on personal computers but can also be exploited in the cloud. We verified the ZombieLoad attack on Intel processor generations released from 2011 onwards. ZombieLoad in Action In our demo, we show how an attacker can monitor the websites the victim is visiting despite using the privacy-protecting Tor browser in a virtual machine. ___ 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)
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&results_type=overview&query=freebsd&search_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: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)
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: CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)
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 by Netflix / Looney? When did FreeBSD become aware of the issue? ___ 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)
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 by, so asking again... This is now into *third* week and *third* time this very simple questions has been asked pursuant "actual discussion around disclosure policies", from two public and at least one private party, with zero response. Optics fogging up. Escalating as such. Thanks. > When was the issue discovered by Netflix / Looney? > When did FreeBSD become aware of the issue? ___ 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)
>>> 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 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 factor 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.. https://www.zdnet.com/article/firefox-zero-day-was-used-in-attack-against-coinbase-employees-not-its-users/ https://tech.slashdot.org/story/15/09/04/206228/bugzilla-breached-private-vulnerability-data-stolen A recent Firefox zero-day that has made headlines across the tech news world this week was actually used in attacks against Coinbase employees, and not the company's users. Furthermore, the attacks used not one, but two Firefox zero-days, according to Philip Martin, a member of the Coinbase security team, which reported the attacks to Mozilla. One was an RCE reported by a Google Project Zero security researcher to Mozilla in April, and the second was a sandbox escape that was spotted in the wild by the Coinbase team together with the RCE, on Monday. The question here is how an attacker managed to get hold of the details for the RCE vulnerability and use it for his attacks after the vulnerability was privately reported to Mozilla by Google. The attacker could have found the Firefox RCE on his own, he could have bribed a Mozilla/Google insider, hacked a Mozilla/Google employee and viewed details about the RCE, or hacked Mozilla's bug tracker, like another attacker did in 2015. > 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 ___ 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"
Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}
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 userbase and project, appropriate resource allocation efficacies, etc. Date_Discovered: Date of original discovery by discoverer. Date_Received: Date project received notification (or observed any info), regardless from external or internal source. Issue should also be posted heads up to lists at this Received time. For apprise those users wishing or needing to performing necessary local review and action prior to formal fix from FreeBSD upstream. And for putting out to community the call to fix. Date_Advisory: Already present as "Announced:" fix. Also ends up being a bit more efficient as fewer cycles need spent on deciding and managing what to witholding timing sched contracts, under whatever questionable premises readily found searching net from thread above. To the extent any of this have possibly applied in the past. Heads Up on receipt, and include targeted fix timeframe guideline for readers based on expected class of fix difficulty selected from prior convened and published policy guide table of difficulties and dependencies. Heads Up and interim are naturally not expected to be a polished Advisory. > This > particular disclosure was a bit unusual as it wasn't external but > instead was an internal FreeBSD developer the security team often works > with. Seems this SACK Discovery was came from Netflix while in that external dev role, not from in purely internal to FreeBSD dev role. And Received was from not Netflix official team role, but by this liason. Fine and moot though, as datestream handling above should apply to all cases. > As such, our process was a bit out of sync with normal (as much as > we have a normal with our current processes). All of that said, we got > notice in early June, about 10 days before public disclosure. Community can ascertain visit any needs adjustments therein with by inclusion of dates and passthrough above. >> Were any FreeBSD derivatives given advanced notice? If so, which ones? > > They were not. I would like to get to a point where we feel we could > give some sort of heads up for downstream, but we aren't there yet. Whether push, or pull via subscribe, derivative third parties are a bit secondary to the closer FreeBSD community processes. ie: Does Linux Kernel push to all 1000 linux distro teams? Probably not, a bit out of scope, so they pull (distro being the derivative depend of kernel there). Again mooted simplicity with better date and passthrough above. ___ 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: Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}
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, outlined in the ongoing threads. > Security Officer is a volunteer position and their time is valuable. > requiring them to do more work to provide information Date_Received adding is not "more work" in any real sense. FreeBSD Project knows when it becomes aware of an issue, readily available in the very same email headers, forum post headers, etc... a minute's cut and paste into an Advisory. That's an easy first step. > that is mostly already available elsewhere? In the Subject example, and many others, no. Discovered and Received dates are often not given. >>Date_Discovered: Date of original discovery by discoverer. > This will be in the linked CVE. It is not present in the current CVE or Netflix or FreeBSD infosheets. If some external discoverer wants to play silly and coy with that Date_Discovered info, fine. However once Date_Received occurs as above, FreeBSD project should be denoting its Date_Received. >>Date_Received: Date project received notification (or >>observed any info), regardless from external or internal source. > > How/why is this relevant? Already explained... it is critical datapoint for user base to review evaluate community allocation of resources to appropriate levels of security response. They might choose months, weeks, days. But without Date_Received, everyone is left in dark, and allocations potentially not wherever they should be to meet general needs. > I agree that the project has been ignored > in some cases but that is generally discussed separately. FreeBSD ignored by external fake security purveyors? If that is the meaning, that would be a good thing, hopefully due to FreeBSD doing things toward real security that counter that. >>Issue should also be posted heads up to lists at this Received >>time. > > Definitely not. Early advice of vulnerabilities is very much "need to > know". Utterly False. If you are the owner... user, admin, entity or even customer with data or services running on... a vulnerable system, it is absolutely without question your need to know. Further, if FreeBSD is not posting a heads up upon its Date_Received of what it knows so far, it is putting itself in very questionable position of claiming to knowing best for all when in fact it does not even know for one, instead of rightly setting those decisions off to systems owners as best suits their own needs via heads up post. > Unless someone's expertise is required to rectify the vulnerability, > details regarding the vulnerability should remain private. What external does is up to them. Yet as herein, once it hits FreeBSD's doorstep, FreeBSD's responsibility is to users first and foremost to point of exclusivly. > The discoverers may > choose to publish early information As above, that's upon them and their cred game. Not forgetting that those discoverers that withold often get caught and look silly. > in which case, the Project may choose > to publicly reference that information. If FreeBSD is independant, it can refer and publish whatever it knows, when it knows it. If it is not, then those aspects of FreeBSD need very serious opening up to sunlight and review by the entire community. Same if FreeBSD were subject to "Donation Capture", that would need reviewed extremely closely. > Public announcement dates are generally not under Project control - where a > vulnerability affects multiple vendors, there is almost always general > agreement on a common announcement date. This is a game, a fake news show meant to make the interviewees look good, typically monied vendors of closed proprietary garbage smelly swiss cheese product, everyone knows it, so just stop. > If the Project leaks information > about unannounced vulnerabilities, it will stop receiving advance > information about vulnerabilities - this definitely will adversely impact > the Project. If FreeBSD is or wants to playing the [vendor] game, wants to become a closed system, subject to such others, etc... it will never be known for pushing the much needed opensource HW and SW philosophy envelope any further ahead into the light through its openness action or even activism. There are enough closed models out there already. Don't let those closed actors fool and play you into their dark traps. FreeBSD hopefully is, and must be, better than that. Here's another example of secrecy serving no one other than dark forces (in this case, literally TLA's and nefarious actors around the world against owners users customers)... https://zerodium.com/program.h
Re: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
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-ization, signing the repo init and later points tags commits, along with full verification toolset, is useful function. https://www.monotone.ca/ https://en.wikipedia.org/wiki/Monotone_(software) https://git-scm.com/ https://en.wikipedia.org/wiki/Git Maintaining the kernel's web of trust https://lwn.net/Articles/798230/ Distributing kernel developer PGP keys via pgpkeys.git https://lkml.org/lkml/2019/8/30/597 Signing patch flow https://lwn.net/Articles/737093/ Compromised security happens https://lwn.net/Articles/464233/ https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-= tags-only-as-safe-as-sha-1-or-somehow-safer https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptograph= ic-hash-function http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki https://ericsink.com/vcbe/html/cryptographic_hashes.html https://svn.haxx.se/dev/archive-2015-06/0052.shtml http://git.661346.n2.nabble.com/Verifying-the-whole-repository-td1368311.ht= ml https://shattered.io/ https://www.youtube.com/watch?v=3DG8wQ88d85s4 https://en.wikipedia.org/wiki/Data_degradation https://git-scm.com/docs/git-fsck https://marc.info/?l=3Dgit&m=3D118143549107708 https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Deterministic_compilation https://www.monotone.ca/monotone.html#Trust-Evaluation-Hooks How does one know their entire copy of repo obtained on DVD, "mirror", or elsewhere cryptographically matches the authoritative repo... that any commits were actually signed off on... or that any reproducible builds are even reproducing the main repo... etc... cannot be done without secure crypto infrastructure at the very core. "User also knows that even if someone should break into the shared hosting server and tamper with the database, they won=E2=80=99t be able to inject malicious code into the project, because all revisions are signed by the team members, and he has set his Trust Evaluation Hooks so he doesn=E2=80=99t trust the server key for signing revisions. In monotone, the important trust consideration is on the signed content, rather than on the replication path by which that content arrived in your database." Note also CVS, which some BSD's still use (ahem: Open, Net), is even worse than SVN with zero protection at all in any component regarding this subject. It really time to migrate repo tech to year 2020. ___ 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: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
[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 ZFS hash merkle-ization, signing the repo init and later points tags commits, along with full verification toolset, is useful function. https://www.monotone.ca/ https://en.wikipedia.org/wiki/Monotone_(software) https://git-scm.com/ https://en.wikipedia.org/wiki/Git Maintaining the kernel's web of trust https://lwn.net/Articles/798230/ Distributing kernel developer PGP keys via pgpkeys.git https://lkml.org/lkml/2019/8/30/597 Signing patch flow https://lwn.net/Articles/737093/ Compromised security happens https://lwn.net/Articles/464233/ https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki https://ericsink.com/vcbe/html/cryptographic_hashes.html https://svn.haxx.se/dev/archive-2015-06/0052.shtml http://git.661346.n2.nabble.com/Verifying-the-whole-repository-td1368311.html https://shattered.io/ https://www.youtube.com/watch?v=G8wQ88d85s4 https://en.wikipedia.org/wiki/Data_degradation https://git-scm.com/docs/git-fsck https://marc.info/?l=git&m=118143549107708 https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Deterministic_compilation https://www.monotone.ca/monotone.html#Trust-Evaluation-Hooks How does one know their entire copy of repo obtained on DVD, "mirror", or elsewhere cryptographically matches the authoritative repo... that any commits were actually signed off on... or that any reproducible builds are even reproducing the main repo... etc... cannot be done without secure crypto infrastructure at the very core. "User also knows that even if someone should break into the shared hosting server and tamper with the database, they won’t be able to inject malicious code into the project, because all revisions are signed by the team members, and he has set his Trust Evaluation Hooks so he doesn’t trust the server key for signing revisions. In monotone, the important trust consideration is on the signed content, rather than on the replication path by which that content arrived in your database." Note also CVS, which some BSD's still use (ahem: Open, Net), is even worse than SVN with zero protection at all in any component regarding this subject. It really time to migrate repo tech to year 2020. ___ 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"
AMD Secure Encrypted Virtualization - FreeBSD Status?
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/launch_security_sev.html "AMD is also using its Secure Processor to enable a couple of key features that we believe aren't getting enough attention: Secure Memory Encryption and Secure Encrypted Virtualization. There's an AES-128 engine inside Epyc's memory controller, with the keys managed by the SEP. If SME is enabled in the system BIOS, all RAM in the system will be encrypted using a single key provided by the SEP and decrypted when requested by the CPU. Expanding upon SME, SEV allows guests' allocated RAM to be encrypted with individual keys, separate from the one used by the host operating system." ___ 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: AMD Secure Encrypted Virtualization - FreeBSD Status?
>> 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 document. Then paste all the key management specs into a ticket with your motherboard vendor and get on them to publish a BIOS release that has proper key management functions. Some BIOS makers have this as selectable options in their BIOS reference build routines... ie: the motherboard maker doesn't have to write any code, they just point and click, and the option appears in a BIOS release for mobo end user customers. Sometimes you have to bug and escalate the mobo makers and threaten to walk your next purchase to another mobo maker to get them to cut and post the new BIOS release. https://www.uefi.org/ https://uefi.org/learning_center/papers https://uefi.org/specsandtesttools https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf https://uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_2019.pdf > The goal would be not to disable secure boot and have FreeBSD running > with a secured bootloader :-) > > At the moment we have insecure boot + insecure kernel + possible > encrypted data partition.. > would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-) Yes. ___ 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: AMD Secure Encrypted Virtualization - FreeBSD Status?
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 that would be needing configuration and awareness. You can search them both. This is one of Intel's papers on its version of memory encryption... https://software.intel.com/sites/default/files/managed/a5/16/Multi-Key-Total-Memory-Encryption-Spec.pdf ___ 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: Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
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 >> 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-ization, >> signing the repo init and later points tags commits, >> along with full verification toolset, is useful function. > > > > > Isn't UNIX(TM) philosophy that a program should do one thing and do it > well? Just because people can't be bothered to learn to use multiple > tools to do *multiple* tasks on the same dataset, is not a reason, let > alone "the reason," to increase any program complexity to orders of > N^M^K^L so that one "foo checkout" does all the things one wants! Was r353001 cryptosigned so people can verify it with a second standalone multiple tool called "PGP", after the first standalone multiple tool called "repo checkout"? Was it crypto chained back into a crypto history so they could treat it as a secure diff (the function of a third standalone multiple tool "diff a b") instead of as entirely separate (and space wasting set of) unlinked independant assertions / issuances as to a state? How much time does that take over time each time vs perhaps loading signed set of keys into repo client config. Is LOGO and tape better because less complex tool than C and disk. > When crypto invalidates a repo, how would it be different > from seeing non ASCII characters in plain ASCII files, or sudden > refusal to compile > one way or another you'd still need to restore > from BACKUP Backup is separate, and indeed a fine practice to help keep for when all sorts of horrors can happen. > crypto IS NOT a substitute for good data keeping > practices. Who said that it was. However it can be a wrapper of proof / certification / detection / assurance / integrity / test over them... a good thing to have there, as opposed to nothing. > Also, what empirical data do you have for repo bitrot/transit > corruption that is NOT caught by underlying media? Why are people even bothering to sha-2 or sign iso's, or reproducible builds? There is some integrity function there. Else just quit doing those too then. Many sources people can find, just search... https://www.zdnet.com/article/dram-error-rates-nightmare-on-dimm-street/ http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf https://www.jedec.org/sites/default/files/Barbara_A_summary.pdf https://en.wikipedia.org/wiki/Data_degradation https://en.wikipedia.org/wiki/ECC_memory https://en.wikipedia.org/wiki/Soft_error Already have RowHammer too, who is researching DiskHammer? Yes, there does need to be current baseline studies made in 2020 across all of say Google, Amazon, Facebook global datacenters... fiber, storage, ram, etc. It is surely not zero errors otherwise passed. Then note all the users who do not run any media, memory, and cables capable of detecting and or correcting garbage. And the claims or data, about "checksums / digests / hashes" that fall short of at least 2^128 odds that strong crypto based repositories can provide. Many do not, and should not, accept less as sufficient standards. What is the worth of your data and instructions producted with some software from some repositories from some hops. Though error is only part of entire possible subject, still however... Lower some risks there too by raising some crypto bars. Be sure to expand "external physical editiing" hinted to include malicious, even by both local and remote adversarial actors, and or those acting outside of established practice. Some crypto repositories require additionally compromise of committer and or distribution private key to impart trust downstream, all of which leaves nice audit, instead of just sneaking in a "vi foo.rcs" or binary equivalent. Cryptographic defense in depth, not prayer. [Sorry not sure which is better mail list] ___ 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"
Git/Mtn for FreeBSD, PGP WoT Sigs, Merkel Hash Tree Based
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-ization, signing the repo init and later points tags commits, along with full verification toolset, is useful function. https://www.monotone.ca/ https://en.wikipedia.org/wiki/Monotone_(software) https://git-scm.com/ https://en.wikipedia.org/wiki/Git Maintaining the kernel's web of trust https://lwn.net/Articles/798230/ Distributing kernel developer PGP keys via pgpkeys.git https://lkml.org/lkml/2019/8/30/597 Signing patch flow https://lwn.net/Articles/737093/ Compromised security happens https://lwn.net/Articles/464233/ https://security.stackexchange.com/questions/67920/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function http://fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki https://ericsink.com/vcbe/html/cryptographic_hashes.html https://svn.haxx.se/dev/archive-2015-06/0052.shtml http://git.661346.n2.nabble.com/Verifying-the-whole-repository-td1368311.html https://shattered.io/ https://www.youtube.com/watch?v=G8wQ88d85s4 https://en.wikipedia.org/wiki/Data_degradation https://git-scm.com/docs/git-fsck https://marc.info/?l=git&m=118143549107708 https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Deterministic_compilation https://www.monotone.ca/monotone.html#Trust-Evaluation-Hooks How does one know their entire copy of repo obtained on DVD, "mirror", or elsewhere cryptographically matches the authoritative repo... that any commits were actually signed off on... or that any reproducible builds are even reproducing the main repo... etc... cannot be done without secure crypto infrastructure at the very core. "User also knows that even if someone should break into the shared hosting server and tamper with the database, they won’t be able to inject malicious code into the project, because all revisions are signed by the team members, and he has set his Trust Evaluation Hooks so he doesn’t trust the server key for signing revisions. In monotone, the important trust consideration is on the signed content, rather than on the replication path by which that content arrived in your database." Note also CVS, which some BSD's still use (ahem: Open, Net), is even worse than SVN with zero protection at all in any component regarding this subject. It really time to migrate repo tech to year 2020. ___ 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: AMD Secure Encrypted Virtualization - FreeBSD Status?
>> 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 motherboards will let you delete the Microsoft keys from the BIOS defaults and install your own. With those boards you do not need Microsoft, or any shims signed by Microsoft, or anyone else but you. See the key management parts of the UEFI SECURE BOOT spec... https://uefi.org/ If your mobo maker does not have full key management options in their latest BIOS, ticket and bug them until they do. ___ 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"
TLS Fingerprint Pinning Needed [ex: for NFS-over-TLS client]
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 CA chain / expiry / etc, validate only the fingerprint. - Validate the CA chain / expiry / etc, and validate the fingerprint. - Validate the CA chain / expiry / etc, ignore the fingeprint. - A TOFU mode. No application that uses TLS should be considered completely featured and security capable without fingerprint pinning functions. For some background reasons on why --pinnedpublickey implementations are now showing up in softwares that speak TLS, and for sample code, and related infos, see the links... https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html https://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html --pinnedpubkey Tells curl to use the specified public key file (or hashes) to verify the peer. This can be a path to a file which contains a single public key in PEM or DER format, or any number of base64 encoded sha256 hashes preceded by 'sha256//' and separated by ';' When negotiating a TLS or SSL connection, the server sends a certificate indicating its identity. A public key is extracted from this certificate and if it does not exactly match the public key provided to this option, curl will abort the connection before sending or receiving any data. Please note this option is rightly more specific covering only the isolated pubkey, not the DER form of the entire "CA signed" cert (ie: not the typically referenced coverage of "openssl x509 -fingerprint"). When fully implemented, this enables a local admin and user environment of more flexible certificate validation service cababilities and security model hardening when subject to various third party things and adversaries like... - Environment of rogue / forced / spy MITM CA's, TLS termination / proxy cloud MITM, VPN / overlay / WiFi networks MITM, etc. - Annoying "expired" certs awaiting tax revenue from their captured audience. - Assigning pinned trust to intermediate CA's such as Lets Encrypt, Google, and corporate schemes, to let edge server certs they sign be freely rotated and or freshly signed without need to update pin. - Avoid need to update pin every "expiry" period. - Avoid CA's by using cert owners publicly available and out of band self certification attestations found on keybase, social, observatories, PGP, etc. - As mentioned above, optionally in combination with other CA / expiry / etc checks, or ignoring the CA altogether. - CRL checks are a massive metadata privacy and user monetization leak that some users might not want exposed to. - Pinning one or both of: pubkey (herein) and or CA (openssl x509 -fingerprint) Another very useful security feature to have is a trust on first use TOFU mode that stores, pins, and subsequently validates against those fingerprints, similar to SSH model. This is useful for both known comms partners such as client-server model, and in more distributed group or even p2p applications to help keep things a bit more locked down by default. Defense (like this pubkey pinning) in depth... you can use it :) References (obviously TLS_1.3 is todays version to use)... https://www.netcraft.com/internet-data-mining/ssl-survey/ https://www.ssllabs.com/ssl-pulse/ https://arstechnica.com/gadgets/2018/10/browser-vendors-unite-to-end-support-for-20-year-old-tls-1-0/ https://www.bleepingcomputer.com/news/security/ietf-approves-tls-13-as-internet-standard/ https://en.wikipedia.org/wiki/Transport_Layer_Security https://tools.ietf.org/html/rfc8446 https://github.com/OWASP/www-community/blob/master/pages/controls/Certificate_and_Public_Key_Pinning.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d https://github.com/curl/curl/blob/deb9462ff2de8e955c67ed441f5f48619a31198d/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3 https://github.com/curl/curl/blob/51fde337471c9125e7bf425e7ce0a0bf53691992/docs/TODO#L728 ___ 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: Plans for git (was: Please check the current beta git conversions)
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/823352/ https://git-scm.com/docs/hash-function-transition ___ 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"
Where's the fingerprints and sigs? (was: Please check the current beta git conversions)
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, and downloads, and packages, forums, and git hashtree initialization first hashes, and pubkey modulus not just the larger DER's by untrusted/attacking CA's, etc... are all not sha-256 fingerprint signed and attested to in a base included textfile, in repo and on website, etc by security officer keys having good WoT... for users to reference, import, validate, pin down, etc. And tools for accessing such services often not have fingerprint pinning options. Woes be to those using such untrustable massively MITM'd and spied upon networks as the Internet, Workplace, Home, Travel, VPN, WiFi, Tor Exits, etc not having any way to authenticate fingerprints and pin such services back to their favorite OS project's security apostille office yet. Security vaunted OpenBSD still serves up via cleartext non-hashtree anoncvs on non-ecc harware on non-zfs-skein filesystems etc... So the BSD world must still be thought secure, bit integral, and trustably accessible without any of these infrastructure tool fingerprint sig and pin basics... still no need to supply them since decades since TLS/SSH/etc were deployed... Right? Not. Cheers all :) [Same for Linux ;] ___ 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: Plans for git (was: Please check the current beta git conversions)
> 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/823352/ > https://git-scm.com/docs/hash-function-transition For those interested, additional topical from same site... https://github.com/bk2204/git/tree/transition-stage-4 https://lwn.net/Articles/823352/ Updating the Git protocol for SHA-256 https://lwn.net/Articles/811068/ A new hash algorithm for Git https://lwn.net/Articles/715716/ Moving Git past SHA-1 https://lwn.net/Articles/813646/ Attestation for kernel patches https://lwn.net/Articles/821367/ Merkle trees and build systems https://lwn.net/Articles/663875/ Changes in the TLS certificate ecosystem, part 1 https://lwn.net/Articles/468911/ Sovereign Keys for certificate verification https://lwn.net/Articles/652580/ Decentralization for the web ___ 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"
12.2R Sigs
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, ftp, rsync, torrent, etc) alongside with the image datasets themselves. If not, the docs can make note of the labels to which sigs apply. ___ 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: 12.2R Sigs
> 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. Whereas repo, website and dataset locations are more predictable and programmatic... allowing fetching, validation, etc. There could be a commit subsequent to tags, to hold all relavant collected metadata results, created sigs, etc of those tagged builds. ___ 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: 12.2R Sigs
>> > 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 RC builds, they are predictable and programmatic. Users would have to get and search the entire lists content to find such sig posts, unfortunately no there are no nice predicted paths to such single emails supporting simple fetch of associated sig infos, ie: no schema :///13.x/.asc Mail are not, it can't... ie: it has no hier, path, file globbing regex *, etc. The website and distribution methods mentioned earlier are possible. (Now just for RC and RELEASE, as clarified in thread.) Website has them in nice paths today, individually... https://www.freebsd.org/releases/12.1R/signatures.html and in bulk... https://www.freebsd.org/releases/12.1R/announce.asc but they are not present in what should be their natural cohabitation set within the other distribution methods, such as the case of https / ftp / rsync / torrent / etc for... https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.1/ > I am not on postmaster. What that mean in context? Only some volunteer for that role, as any other, it's ok not to be in two or more of them. ___ 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: 12.2R Sigs
> [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 breaking points, which can and do fail in various ways. Distributed cloneable distributable repo's based on crypto are needed to do that, perhaps such as Monotone, or at least sign Git's init hash. https://monotone.ca/ https://git-scm.com/ > announce.asc file is only created for the final RELEASE build Yes as those are nice milestones :) ___ 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: AMD's memory encryption (aka SME)
> 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 rowhammer, cold boot attacks, shared hosting, VM, poison, etc... there are papers on some use cases. AMD SME has some different levels with EPYC being full featured, TR and PRO differently, than even consumer cpu last. FreeBSD should also implement sysctl that writes random to all memory (even over kernel) just before halt / reboot call. Similar for unallocated upon sleep, upon alloc release, and as background scrub. User can already choose random upon alloc with malloc.conf but that is different than above. Also: memtest86[+] integration. ___ 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"
CA's TLS Certificate Bundle in base = BAD
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. - Undetected stolen unrevoked unchecked CA's, intermediates, server keys, etc. - Total/targeted IP/DNS traffic user interception by agents, vpn's, proxies, tor, mitmproxy, sslstrip, etc. - Base asserting trust over all that, when reality none is due. There should be no non-FreeBSD.Org/Foundation CA's shipped in base. Its shipped pubkey fingerprint sets can bootstrap TLS infra pubkeys/prints off bsd keyserver, to then pubkey pin TLS fetch(1) / pkg(8) / git(1) to reach pkg ca_root_cert, git src ports repos, update, iso, etc. See curl(1) --pinned-pubkey, GPG, etc. https://www.zdnet.com/article/surveillance-firm-asks-mozilla-to-be-included-in-firefoxs-certificate-whitelist/ https://en.wikipedia.org/wiki/Edward_Snowden https://duckduckgo.com/?q=rogue+CA+root+certificate https://www.win.tue.nl/hashclash/rogue-ca/ Users should delete all those ~139 garbage CA's, only add in the ones they find they need during use, easily scripted and tooled, start with say the... - LetsEncrypt chain And force TLS pubkey fingerprint pin check on critical services. Search web for howtos. At minimum require user / install to ack before use... mv /etc/ssl/certs.shipped_disabled /etc/ssl/certs ___ 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"
AMD: Predictive Store Forwarding PSF
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 vulnerable to Spectre-like side-channel attacks. Called Predictive Store Forwarding (PSF), this feature was added to AMD CPUs part of the company's Zen 3 core architecture. ___ 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: OpenZFS port updated
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 this >> is zfs filesystem level encryption and not a replacement for our existing >> full-disk-encryption scheme that currently works? > > I’m not aware of a good current doc for this. If anyone finds/writes > something, please post it! > There are some old resources you can find with a quick search that do a > pretty good job of covering the basic ideas, but I think the exact syntax of > commands may be slightly changed in the final implementation. > > The encryption is performed at a filesystem level (per-dataset). You could find some initial doc and video about zfs encryption on openzfs.org and youtube, and in some commit logs. Therein was mentioned... People are needed to volunteer to expand documentation on the zfs crypto subject further in some document committed to openzfs repo since users and orgs will want to know it when considering use. Volunteers are also sought by openzfs to review the crypto itself. Maybe there was already some central place made with further current documentation about the zfs encryption topics since then? https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view It's dataset level, so GELI or GBDE etc are needed for full coverage, perhaps even those two may not have yet received much or formal review either, so there is always good volunteer opportunity there to start with review of a potentially simpler cryptosystem like those. zfs list, dataset snapshot names properties etc not covered. zfs history not covered, many sensitive strings will end up in there, including cutpaste password typos into commandline, usernames, timestamps, etc... and no tool exist to scrub overwrite history extents with random data, and no option exists to turn keeping of 'user initiated events' or 'long format' off, and ultimately no option exists to tell zpool create to disable history keeping from the very start entirely. So maybe users have to zero disks and pools along with it just to scrub that. zfs also exposes these variety of path and device names, timestamps, etc in cleartext on disk structures in various places, including configuration cachefile... Some of those could could be NULLed or dummied with new zpool create options for more security restricted use cases. There are other meta things and tools left exposed such as potentially any plaintext meta in send/recv. Another big metadata leak for environments and users that ship, sell, embed, clone, distribute, fileshare, and backup, their raw disks pools and usbs around to untrusted third parties... is that zfs also puts hostnames and UUID type of unique static meta and identifying things in cleartext on disk. zfs thus needs options to allow users to set and use a NULL, or generic dummy default, or random string, or chosen, "hostname" for those from the very first zpool create command. Most applications users use, including zfs, can today consider ways in which metadata leaks could be removed entirely, or at least optioned out for use under high security restricted environments modes. That could even involve considering trading off some extra features not actually required for a basic mode of functionality of the app. (cc's for fyi inclusion about leaks, and as lists still haven't been configured to support discreet bcc for that purpose, which would also maintain nice headers for thread following. Gmail breaks threads. zfsonlinux topicbox can't subscribe without web. Drop non-relevant cc's from further replies. Parent thread from freebsd current and stable lists was Subject: OpenZFS port updated) ___ 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"
OpenZFS Encryption: Docs, and re Metadata Leaks
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 this >> is zfs filesystem level encryption and not a replacement for our existing >> full-disk-encryption scheme that currently works? > > I’m not aware of a good current doc for this. If anyone finds/writes > something, please post it! > There are some old resources you can find with a quick search that do a > pretty good job of covering the basic ideas, but I think the exact syntax of > commands may be slightly changed in the final implementation. > > The encryption is performed at a filesystem level (per-dataset). You could find some initial doc and video about zfs encryption on openzfs.org and youtube, and in some commit logs. Therein was mentioned... People are needed to volunteer to expand documentation on the zfs crypto subject further in some document committed to openzfs repo since users and orgs will want to know it when considering use. Volunteers are also sought by openzfs to review the crypto itself. Maybe there was already some central place made with further current documentation about the zfs encryption topics since then? https://www.youtube.com/watch?v=frnLiXclAMo openzfs encryption https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view https://www.youtube.com/watch?v=kFuo5bDj8C0 openzfs encryption cloud https://drive.google.com/file/d/14uIZmJ48AfaQU4q69tED6MJf-RJhgwQR/view It's dataset level, so GELI or GBDE etc are needed for full coverage, perhaps even those two may not have yet received much or formal review either, so there is always good volunteer opportunity there to start with review of a potentially simpler cryptosystem like those. zfs list, dataset snapshot names properties etc not covered. zfs history not covered, many sensitive strings will end up in there, including cutpaste password typos into commandline, usernames, timestamps, etc... and no tool exist to scrub overwrite history extents with random data, and no option exists to turn keeping of 'user initiated events' or 'long format' off, and ultimately no option exists to tell zpool create to disable history keeping from the very start entirely. So maybe users have to zero disks and pools along with it just to scrub that. zfs also exposes these variety of path and device names, timestamps, etc in cleartext on disk structures in various places, including configuration cachefile... Some of those could could be NULLed or dummied with new zpool create options for more security restricted use cases. There are other meta things and tools left exposed such as potentially any plaintext meta in send/recv. Another big metadata leak for environments and users that ship, sell, embed, clone, distribute, fileshare, and backup, their raw disks pools and usbs around to untrusted third parties... is that zfs also puts hostnames and UUID type of unique static meta and identifying things in cleartext on disk. zfs thus needs options to allow users to set and use a NULL, or generic dummy default, or random string, or chosen, "hostname" for those from the very first zpool create command. Most applications users use, including zfs, can today consider ways in which metadata leaks could be removed entirely, or at least optioned out for use under high security restricted environments modes. That could even involve considering trading off some extra features not actually required for a basic mode of functionality of the app. (cc's for fyi inclusion about leaks, and as lists still haven't been configured to support discreet bcc for that purpose, which would also maintain nice headers for thread following. Gmail breaks threads. zfsonlinux topicbox peole can't subscribe without javabloatbroken website, so someone could forward this there. Drop non-relevant cc's from further replies. Parent thread from freebsd current and stable lists was Subject: OpenZFS port updated) ___ 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"
RNGs in Operating Systems
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/
Re: Adding entropy from external source into random number generator - how?
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 how RNG cards attach even in /dev... random(4) random_harvest(9) random_fortuna kern.random.harvest.mask_symbolic crypto(4) crypto(9) rndtest(4) > I believe it's also possible to open /dev/random for write to inject entropy > but I cannot find any mention of that scenario in the man pages. Using serial port as entropy source (either as interrupt and/or data), even USB video audio radios environmentals, might already have a handbook or wiki page, if not then interested users could make one. If injecting that data isn't in random(4), a script example of that is in... /etc/rc.d/random Along with some entropy file parts mentioned in... loader.conf(5) rc.conf(5) The choice of 4096 bytes should be documented. Search also ports for RNG things. > whether ~45 kilobytes per second of > additional entropy is even useful in a typical situation? CSPRNGs often try not to break no matter how much output is read, accept a bit-equivalent amount of random seed (ie 256-bits), and are speed limited only by cpu system. If doing only this: "HWRNG_stream XOR plaintext_stream", then in that case you could only get ~45kB/s throughput. > All entropy is good entropy, right? At least one source must be good. Having more good sources monitored and feeding into things can serve as redundant coverage. Search: Claude Shannon, one time pad, XOR, CSPRNG, HWRNG, applications such as casinos bitcoin keygeneration fobs, fun sources to collect, etc.
Re: Lack of notification of security notices
> 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 delivery copy. Try importing the raw mboxes in question to search for the messages in question. > how the mailer treats cross-posts. Bcc's should also be enabled to deliver and show up, Bcc as reduced form of Cc still helps with inclusion, and also helps keep 'group / all' replies going to primary.
CPU "Bugs" Hardly Considerable As Inspectably Innocent [Re: Intel/AMD CVE's]
>> 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-israels-secret-startup-machine/ https://techcrunch.com/2015/03/20/from-the-8200-to-silicon-valley Never fail the chance that NSA GCHQ CIA FSB Mossad/MID etc may consider the inexplicably continuing long history of "bugs" as friendly and conveniently embedded features, partnerships if you will... And that you can't escape that, nor have anything other than a black box, by continuing to foolishly rely on either of those Govt Corp... TOP-SECRET and Corporations have sordid opaque history of snakeoil, malware, spyware, suspect changes, etc. You can't see inside it, you cannot trust it. Abandon those old invisible models and sketchy indoctrination programs, reboot your brains to the open, connect the webcam to the microscope and push it at least 10x closer for all to see, do something different, and profit, ftw... #OpenFabs , #OpenHW , #OpenAudit , #FormalVerification , #CryptoCrowdFunding , #OpenTrust Have fun :)
Re: Retbleed, another speculative execution attack
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 mitigations published - Were those or others applied Point everyone there.
Re: Retbleed, another speculative execution attack
>> 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.freebsd.org/SpeculativeExecutionVulnerabilities Cool, yes, more or less. Though that one may be missing some number of hardware (HW) vulnerabilities. They are a distinct space imposed on OS's by upstream HW makers (as opposed to self-imposed SW kernel, user, app, compiler, etc bugs), ambitious wiki'ers could track them all the way back to F00F, etc. Though only those HW bugs with actual or suspected potential for an exploitable security vector would need listed, not simple lockups, reboots, incorrect return status or data, as in the typical HW errata sheets. Maybe some organizing updates... Background and other generic upstream literature could by now be replaced with a few overall wikipedia links. Try one bug per row by its canonical links and name (usually CVE) to show BSD saw and signed off in what ways on each (whichever among ticket, review, commit, mail thread). Only the per bug list of 'fixes/mitigs available' and 'fixes/mitigs applied' matters to users. 'Vulnerable' or 'not vulnerable' is meta curation that really only matters to legacy hardware shoppers and critiquers of HW makers, and is already available in the offsite literature. The HEAD signoff is more important to track for long term reference than maintaining list of EOL major.minor's when that info already flows from and within links to the head work anyway. In the interest of importance on first glance "seen and signed off, didn't totally miss a CVE somewhere" aspect. >From there, whatever level of work-from flow matrix and detail can then follow. Someone failed to post their reply to the list... " FreeBSD doesn't have a fix for that one, but it also doesn't have fixes for Spectre V1, Spectre-BHB, or MMIO Stale Data. FreeBSD is still a sitting duck for these CPU vulns, so adding yet another one on top doesn't really matter. " And please quit top-posting... replies belong below what you are replying to so people can linearly follow entire context like a book top to bottom, and don't have to labor to fix the disorderly mess you created when they reply to it.
Re: Putting OPIE to rest
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 At least so long as PAM remains available, OPIE should be maintained as a PAM option, and be updated. OPIE is the only PAM that allows printing out the future secure tokens. Old school, secure, it just works. HOTP requires hardware, TOTP requires time, neither are printable, both of those require some other [hackable] hw/sw device that costs $$$ money, and those devices all have different threat/failure/admin models than simple paper. If people don't like... - The hash algo, a volunteer committer can update it to sha256. - The list of words, a volunteer committer can update it to read from a list of admin supplied words in: /etc/opie_words.txt - The number of words, a volunteer committer can add an option to the config for that. - The writeable state breaking in a read-only root, a volunteer committer can add a config option to point that elsewhere. - The randomness, a volunteer committer can update it to modern randomness. And if people still don't like it, then commit those simple updates, and push it out to ports, instead of killing users use of it.
Re: Putting OPIE to rest
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 ones that do? OPIE's model already intends for and supports no-device and printout. To emphasize and extend... https://lists.freebsd.org/archives/freebsd-current/2022-September/002573.html It should also be noted that the affected scope here is not just 'FreeBSD users logging into FreeBSD shell', there are also applications out there that compile against and use FreeBSD's libopie, some of which are in ports some are not. OPIE does not exist as a port+package, thus re POLA for users, it should not be removed until such time as one is provided. Where is discussion on these. And why isn't every other 'old, outlived, non-hipster' pam authentication plugin being arbitrarily removed and non-portified, such as say tacacs, radius, krb, rhosts, etc. And if those pam are there, why then are hip OAUTH HOTP TOTP etc type things not added, lib-ified, etc.
Black Box Executes Assembly ABI, Yet Which Masters Loom
> 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 now found with fuzzers, "bugs", exploits, off by one "oops" in that ancient commit, "Will Not Fix "Errata"". A world full of agents spies moles and crypto-corrupting GovCorps, phones remotely controllable via baseband, package interception mitm, etc. The average kernel bigger than Encyclopedia. No, it's entirely plausible that what you think is "your" black box to play master level of Tetris on, is actually someone else's just waiting for that magic packet or execution pattern, always on, backed up to the connected cloud, auto updated, AI enhanced, datamined, and oh my those alluring honeytraps... Cortana Alexa and Ring. " Communication in a world of pervasive surveillance Sources and methods: Counter-strategies against pervasive surveillance architecture ISBN: 978-90-386-5471-3 March 2022 The Adversary 4.4 - Standardization of cryptographic sabotage p.81 4.6 - ANT Catalog p.92 " Demand and participate in the creation, startup, and purchase of... #OpenFabs , #OpenHW , #OpenAudit , #FormalVerification , #CryptoCrowdFunding , #OpenTrust , #GuerrillaNets , ... Your Freedom may well depend on it. "Wer die Wahrheit nicht weiß, der ist bloß ein Dummkopf. Aber wer sie weiß und sie eine Lüge nennt, der ist ein Verbrecher." 1 -- Bertold Brecht, Das Leben des Galilei, Seite 71
Re: FreeBSD Security Advisory FreeBSD-SA-22:15.ping
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 Micro$haft Crapple Phones would be even more a convenient gift to various actors. Perhaps the real question is... Why is ping, repeatedly over history, like sendwhale, still being written such that it remains exploitable...
Re: CA's TLS Certificate Bundle in base = BAD
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 empty file... and quit trusting bundles of hundreds of random CA's, all of which are entities who have zero duty or care to the user, and often exist/corrupt/break to present evil [2] ... [1] https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3 FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option, thus they're incapable of securely fetching packages, iso's, etc from servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys for users to get, verify, and pin out of band. Even pubkeys were swapped out on FreeBSD servers without announcing for users if any exploit or loss occurred there or for some other reason. That's all bad news :( But can be fixed :) [2] https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections https://www.msn.com/en-us/news/technology/mysterious-company-with-government-ties-plays-key-internet-role/ar-AA13RwPh https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ Major Web Browsers Drop Mysterious Authentication Company After Ties To US Military Contractor Exposed TrustCor Systems vouches for the legitimacy of websites. But its physical address is a UPS Store in Toronto. Mysterious company with government ties plays key internet role An offshore company that is trusted by the major web browsers and other tech companies to vouch for the legitimacy of websites has connections to contractors for U.S. intelligence agencies and law enforcement, according to security researchers, documents and interviews. Google’s Chrome, Apple’s Safari, nonprofit Firefox and others allow the company, TrustCor Systems, to act as what’s known as a root certificate authority, a powerful spot in the internet’s infrastructure that guarantees websites are not fake, guiding users to them seamlessly. The company’s Panamanian registration records show that it has the identical slate of officers, agents and partners as a spyware maker identified this year as an affiliate of Arizona-based Packet Forensics, which public contracting records and company documents show has sold communication interception services to U.S. government agencies for more than a decade. One of those TrustCor partners has the same name as a holding company managed by Raymond Saulino, who was quoted in a 2010 Wired article as a spokesman for Packet Forensics. Saulino also surfaced in 2021 as a contact for another company, Global Resource Systems, that caused speculation in the tech world when it briefly activated and ran more than 100 million previously dormant IP addresses assigned decades earlier to the Pentagon. The Pentagon reclaimed the digital territory months later, and it remains unclear what the brief transfer was about, but researchers said the activation of those IP addresses could have given the military access to a huge amount of internet traffic without revealing that the government was receiving it. The Pentagon did not respond to a request for comment on TrustCor. TrustCor also did not respond to a request for comment. [Minutes before Trump left office, millions of the Pentagon’s dormant IP addresses sprang to life] TrustCor’s products include an email service that claims to be end-to-end encrypted, though experts consulted by The Washington Post said they found evidence to undermine that claim. A test version of the email service also included spyware developed by a Panamanian company related to Packet Forensics, researchers said. Google later banned all software containing that spyware code from its app store. A person familiar with Packet Forensics’ work confirmed that it had used TrustCor’s certificate process and its email service, MsgSafe, to intercept communications and help the U.S. government catch suspected terrorists. “Yes, Packet Forensics does that,” the person said, speaking on the condition of anonymity to discuss confidential practices. Packet Forensics counsel Kathryn Temel said the company has no business relationship with TrustCor. She declined to say whether it had had one previously. The latest discovery shows how the technological and business complexities of the internet’s inner workings can be leveraged to an extent that is rarely revealed. Concerns about root certificate authorities, though, have come up before. In 2019, a security company controlled by the government of the United Arab Emirates that had been known as DarkMatter applied to be upgraded to top-level root authority from intermediate authority with less independence. That followed revelations about DarkMatter hacking dissid
Re: Add BLAKE3 hash to ISO checksums
> 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 > Executed in7.39 secs > Executed in4.84 secs Any given hash function will take the same time for the same data. Something in the system or test setup is likely returning any "17x" difference or lack thereof... ie caching. Until that outlier difference is investigated and identified, any speed differences between hash functions wouldn't necessarily be reason to add or drop any of them. Use ramdisk on dedicated or non-busy testbeds, specify exact cpu model if testing cpu features or desiring others to scale results to their own cpu's, average results across multiple runs, don't publish outliers unless exploring degenerate edge cases, etc. > I recommend using https://crates.io/crates/b3sum The actual reference implementation source code is here... https://github.com/BLAKE3-team/BLAKE3 > Can we please add BLAKE3 hashes to > https://www.freebsd.org/releases/13.1R/signatures ? Two well chosen hash functions should be enough to cover a break in one, and a third seems a bit overkill. FreeBSD doesn't really use or embed them much and it can swap out broken algos faster than entities in the world that may have hardcoded them in non-modular things. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptography If choosing crypto algos, the obvious will be one that are recognized by crypto standards bodies, competitions, and communities worldwide, and are in wide growing adopted use as a result of those processes. Some of them may be listed starting from the above links. Then whatever alternative competitors based on reviewed security estimates, speed, family isolation by both authorship and algorithm approach, cross platform, multi-thread, simplicity, programmability, arbitrage of threat model/actor/geopolitic, Post-Quantum, etc chosen from among the different algos. FreeBSD's current choice of sha-256 and sha-512 do fail some of those differentiators, thus it is probably reasonable to consider swapping one of them out. More of the leading competitors reference crypto implementations could be added to FreeBSD ports and packages for people to play with. There are also some dedicated all-in-one multi-hashing apps that volunteers could also make ports of. Tools like 'openssl dgst' already do include some, and there are crypto libraries for Python, etc.
12.4R Image Sigs Missing
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 the image sigs were forgotten to be put in 1st link above, or are not in the release checklist for people to follow, or were deemed redundant but theiir link blurb was not dropped from announce.asc, etc...
Re: cant login after make installworld: pam_opie.so.6 not found
>> 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 Revision: https://reviews.freebsd.org/D36592 This appeared as perhaps an arbitrary deletion change for some unknown non-discussed reason. Someone else posted the problems, user features, and alternatives that would preserve and update use of OPIE options for FreeBSD users, but again, no one discussed. So now users are getting locked out and have one less security option available to them in FreeBSD. https://lists.freebsd.org/archives/freebsd-security/2022-September/ https://lists.freebsd.org/archives/freebsd-security/2022-October/ There is still good opportunity therein to restore some implementation of it for FreeBSD. Welcome to 2023 :)
Re: Putting OPIE to rest (was: Re: cant login after make installworld: pam_opie.so.6 not found)
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 before the removal was taken.
Opie is not some hi-maint lo-api-compat legacy driver holding back
kernel dev, it's a tiny stable user app plugin that just works for decades.
Now users are posting locked out, punted to deploy non-replacements,
and can't even compile it back because code gone from trees in use.
There was hardly reason to remove it (lots of other things could be
considered "outlived usefulness" but don't get removed), and even
if so (as perhaps part of say some larger discuss on pam), there
was zero reason for the removal team not to portify it given
FreeBSD has already set good example of moving even
large/complex user apps from base to ports.
That should have, and still should be done, with opie.
Consider on that process for future,
rather than whatever is thought of some app.
Cheers.
Cc: ports, as the lo-maint hi-api-compat opie could also be
used to +1 their competitive 35k count :)
See also compat{M}x-{arch} packages.
> https://lists.freebsd.org/archives/freebsd-current/2022-September/002565.html
> https://lists.freebsd.org/archives/freebsd-hackers/2022-September/001479.html
> https://lists.freebsd.org/archives/freebsd-security/2022-September/81.html
Re: cant login after make installworld: pam_opie.so.6 not found
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 a decade. And further left opie vulnerable and present since the commit in all RELENG, STABLE, and handbook. And did not issue a SA on it since the commit, nor ever since the article. If attempting to claim security as reason to delete, then FreeBSD might appear to be faulty of this. Which would present good opportunity to consider any potential improvements to that process too. > And this could have been avoided if user have followed source upgrade Lockout avoided... yes maybe if users wanted to quit their opie forever at that moment, but if not, then opie code module hasn't yet been moved to ports for anyone to use and or update as they wish. The nature of port security in every unix OS is 3rd-party and un-dedicated, so that wouldn't be reason not to port such things either. Onward :)
Re: Can security/ca_root_nss be retired?
> /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 to read and actively choose to enable footshooting, now apparently the teaching is that blindly placing trust upon untrustable external third parties is the right thing to do. There are lots of MITM enabling random adversaries in that "trust" store, and its issues have been in the news multiple times already. However users choose to disable and manage their own stores, some of their models for doing that obviously might include making use of data elements held within a current port of the upstream stores. Other users have other projects and apps that need it for other reasons as well. So retiring ca_root_nss would be anti-helpful for them, and thus retiring it is definitely not suggested. Nor do other unix retire this either. -- https://odysee.com/@Anarchast:2 https://duckduckgo.com/?ia=videos&iax=videos&q=voluntaryism https://duckduckgo.com/?ia=videos&iax=videos&q=cryptocurrency https://bitchute.com/ https://rumble.com/
Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli
Did anyone check if -j/-J might have similar edge cases?
Re: FreeBSD Security Advisory FreeBSD-SA-23:01.geli
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 printf '\000' printf '\n' printf ' ' printf 'notthekey' and only cat /path/to/your/keyfile | geli should work.
Re: Zenbleed
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 contains some mitigation. Try loading it to those platforms and testing the exploit against them to see. b250b32ab1d044953af2dc5e790819a7703b7ee6 https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures Microcode firmware is literally TOP-SECRET//SCI weaponized magic packet voodoo silo black team stuff, thus updates usually don't get consistent glossy docs publication coordination, let alone exactly what all is being applied to which chips by which releases. More interesting solutions are out there for you to start and join... #OpenFabs , #OpenHW , #OpenAudit , #FormalVerification , #CryptoCrowdFunding , #OpenTrust , #GuerrillaNets , #P2PFiber , #GNURadioRF , #PrivacyCoins , #DropGangs , ...
Re: Downfall microcode update
> 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 from bios before executing any other code (ie from disk). So unless you able to rebuild your own bios images on old boards whose makers are too lame to support updates from upstream cpu vendor, then the next earliest and thus most correct way is have loader load it into cpu first... in case kernel does use the cpu ops that the ucode modifies. The rc way could be there for easier config switch from bad ucode in single user mode. At least Intel has revoked at least one ucode for problems before, but probably not yet for one that locked up anyone's basic kernel load, boot, or user shell. So rc kindof doesn't need to exist given loader way, and that reboot repair methods still exist. > cron >From the HW vendors cpu repos could work, no need to hammer fbsd site for that, but a bit overkill unless you're a shared hosting service, the big guys get advance notice anyway. Nor is anyone sane doing cron fetch and installworld to apply new code either like that.
Re: Is ZFS native encryption safe to use?
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 > dataset to a new encrypted (ZFS native) one, but then got my doubts > about doing that (looking at all the different open GitHub issues on > OpenZFS). > > There exist some rumors about the original company which did the ZFS > native encryption work (the person doing the work left the company), > and they haven't done more since. > > What is the general experience running with ZFS native encryption on > FreeBSD? Is it better to use GELI for the whole pool instead? Neither GELI, nor the rest of the crypto subsystem, nor the kernel, nor userland... has ever undergone anything close to a real security audit, let alone an independent one, let alone been formally verified. And agents, moles, malactors, bugs, and worse are running rampant across the entire computing spectrum... from fab, to shipping, to OS and crypto development, to magic packets, to telecom, to phones, to firmware, software, apps, and updates, BGP, your ISP, frontdoor, backdoor, back orifice, and more. Your use of any crypto, on any operating system, on any hardware platform, on any network, is entirely at your own risk. Still lots of fun yet to be had... #OpenFabs , #OpenHW , #OpenAudit , #FormalVerification , #CryptoCrowdFunding , #OpenTrust , #GuerrillaNets , #P2PFiber , #GNURadioRF , #PrivacyCoins , #DropGangs , ... -- https://www.youtube.com/watch?v=xWAwK2fHArc https://www.youtube.com/watch?v=_U3lEc-IFr8 https://duckduckgo.com/?ia=videos&iax=videos&q=voluntaryism https://odysee.com/@Anarchast:2 https://bitchute.com/ || https://rumble.com/ https://twitter.com/NameRedacted247 https://libertarianinstitute.org/books/voluntaryist-handbook/
