- cypherpunks@lists.ogf.org

Israel Latest: UN Security Council Backs Call for Gaza Truce
by Gunnar Larson 15 Nov '23

15 Nov '23

Israel Latest: UN Security Council Backs Call for Gaza Truce https://www.bloomberg.com/news/articles/2023-11-15/israel-latest-troops-ent… The United Nations Security Council approved a resolution calling for humanitarian pauses in the fighting in Gaza and the release of all hostages held by Hamas, after four similar measures were blocked since the war began.

1 0

AnandTech: Kioxia's CD8P SSD Unveiled: Up to 30.72 TB, PCI 5.0 x4 Interface
by jim bell 15 Nov '23

15 Nov '23

30 terabytes. A million times larger than the biggest I ever sold, in 1992. 31 years ago. Inventor of the SSD, 1980. 43 years ago. Jim Bell, SemiDisk Systemshttps://www.anandtech.com/show/19998/kioxias-cd8p-ssd-unveiled-up-to…

2 2

Hacks: Reptar - Intel Fucks Itself, And You, Again
by grarpamp 15 Nov '23

15 Nov '23

Under the cover of 10's of Billions of gates on die... Half the "bugs" are intentional "features" aka: exploits. The rest are fuckups. Intel is building USA fabs to "secure" its compute, lol. #OpenFabs #OpenHW https://lock.cmpxchg8b.com/reptar.html Reptar Tavis Ormandy Introduction Discovery Solution Notes We have a CPU mystery! We found a way to cause some processors to enter a glitch state where the normal rules don’t apply, but what does that mean…? If you’re interested what can go wrong inside modern CPUs, read on! Introduction If you’ve ever written any x86 assembly at all, you’ve probably used rep movsb. It’s the idiomatic way of moving memory around on x86. You set the source, destination, direction and the count - then just let the processor handle all the details! lea rdi, [rel dst] lea rsi, [rel src] std mov rcx, 32 rep movsb The actual instruction here is movsb, the rep is simply a prefix that changes how the instruction works. In this case, it indicates that you want this operation repeated multiple times. There are lots of other prefixes too, but they don’t all apply to every instruction. Prefix Decoding An interesting feature of x86 is that the instruction decoding is generally quite relaxed. If you use a prefix that doesn’t make sense or conflicts with other prefixes nothing much will happen, it will usually just be ignored. This fact is sometimes useful; compilers can use redundant prefixes to pad a single instruction to a desirable alignment boundary. Take a look at this snippet, this is exactly the same code as above, just a bunch of useless or redundant prefixes have been added: rep lea rdi, [rel dst] cs lea rsi, [rel src] gs gs gs std repnz mov rcx, 32 rep rep rep rep movsb Perhaps the most interesting prefixes are rex, vex and evex, all of which change how subsequent instructions are decoded. Let’s take a look at how they work. The REX prefix The i386 only had 8 general purpose registers, so you could specify which register you want to use in just 3 bits (because 2^3 is 8). The way that instructions were encoded took advantage of this fact, and reserved just enough bits to specify any of those registers. Simple 2-byte instructions that use modr/m might be encoded like this, for example mov eax, ebx. This is an 8-bit opcode, 2 bit addressing mode (labeled m), and 3 bits each for the source (s) and destination (d). Well, this is a problem, because x86-64 added 8 additional general purpose registers. We now have sixteen possible registers..that’s 2^4, so we’re going to need another bit! 😆 The solution to this is the rex prefix, which gives us some spare bits that the next instruction can borrow. When we’re talking about rex, we usually write it like this: rex.rxb rex is a single-byte prefix, the first four bits are mandatory and the remaining four bits called b, x, r and w are all optional. If you see rex.rb that means only the r and b bits are set, all the others are unset. These optional bits give us room to encode more general purpose registers in the following instruction. The rex prefix can lend the next instruction extra bits to use for operands, so now we can encode all 16 possible general purpose registers! Now we’re fine until someone adds another register! 😂 Encoding Rules So now we know that rex increases the available space for encoding operands, and that useless or redundant prefixes are usually ignored on x86. So… what should this instruction do? rex.rxb rep movsb The movsb instruction doesn’t have any operands - they’re all implicit - so any rex bits are meaningless, right? If you guessed that the processor will just silently ignore the rex prefix, you would be correct! Well… except on machines that support a new feature called fast short repeat move! We discovered that a bug with redundant rex prefixes could interact with this feature in an unexpected way and introduce a serious vulnerability, oops 🙂 Fast Short Repeat Move FSRM is a new feature introduced in Ice Lake that fixes some of the shortcomings of ERMS. Hopefully that clears up any confusion. 😆 Just kidding, let’s quickly look at ERMS. The hard part of moving strings around efficiently is getting all the buffers aligned so you can use the widest possible stores available. You could do this in software, but if we do it in microcode then the processor can just transparently make your existing code faster for you. This requires some expensive setup, but once that’s done you get vastly improved throughput. This feature is known as enhanced repeat move/store, ERMS. If you have a processor with ERMS support, simple rep movsb operations can sometimes perform comparably with more complicated hand-tuned vector move operations. However, there is a problem with ERMS. That initial setup is so expensive that it just isn’t worth it for very short strings. This is what FSRM is designed to solve, it handles the case of only moving 128 bytes or less and makes that faster too! I’m not aware of any documentation that explains exactly how FSRM works, but you can check if you have a processor that supports it by looking at the flags line in /proc/cpuinfo: flags : fpu vme de pse tsc msr pae mce cx8 [...] fsrm Some of the processors that have this feature include: Ice Lake Rocket Lake Tiger Lake Raptor Lake Alder Lake Sapphire Rapids Note: This list may not be comprehensive, please see Intel advisory INTEL-SA-00950 for a complete list. Discovery I’ve written previously about a processor validation technique called Oracle Serialization that we’ve been using. The idea is to generate two forms of the same randomly generated program and verify their final state is identical. You can read more about Oracle Serialization in my previous writeup. In August, our validation pipeline produced an interesting assertion. It had found a case where adding redundant rex.r prefixes to an FSRM optimized rep movs operation seemed to cause unpredictable results. We observed some very strange behavior while testing. For example, branches to unexpected locations, unconditional branches being ignored and the processor no longer accurately recording the instruction pointer in xsave or call instuctions. Oddly, when trying to understand what was happening we would see a debugger reporting impossible states! This already seemed like it could be indicative of a serious problem, but within a few days of experimenting we found that when multiple cores were triggering the same bug, the processor would begin to report machine check exceptions and halt. We verified this worked even inside an unprivileged guest VM, so this already has serious security implications for cloud providers. Naturally, we reported this to Intel as soon as we confirmed this was a security issue. Reproduce We’re publishing all of our research today to our security research repository. If you want to reproduce the vulnerability you can use our icebreak tool, I’ve also made a local mirror available here. $ ./icebreak -h usage: ./icebreak [OPTIONS] -c N,M Run repro threads on core N and M. -d N Sleep N usecs between repro attempts. -H N Spawn a hammer thread on core N. icebreak: you must at least specify a core pair with -c! (see -h for help) The testcase enters what should be an infinite loop, and unaffected systems should see no output at all. On affected systems, a . is printed on each successful reproduction. $ ./icebreak -c 0,4 starting repro on cores 0 and 4 ......................................................................... ......................................................................... ......................................................................... ......................................................................... ......................................................................... In general, if the cores are SMT siblings then you may observe random branches and if they’re SMP siblings from the same package then you may observe machine checks. If you do not specify two different cores, then you might need to use a hammer thread to trigger a reproduction. Analysis We know something strange is happening, but how microcode works in modern systems is a closely guarded secret. We can only theorize about the root cause based on observations. μops The CPU is split in two major components, the frontend and the backend. The frontend is responsible for fetching instructions, decoding them and generating μops to send to the backend for execution. The backend executes instructions out of order, and uses a unit called the ROB, reorder buffer, to store and organize results. We believe this bug causes the frontend to miscalculate the size of the movsb instruction, causing subsequent entries in the ROB to be associated with incorrect addresses. When this happens, the CPU enters a confused state that causes the instruction pointer to be miscalculated. The machine can eventually recover from this state, perhaps with incorrect intermediate results, but becoming internally consistent again. However, if we cause multiple SMT or SMP cores to enter the state simultaneously, we can cause enough microarchitectural state corruption to force a machine check. Questions I’m sure some readers will have questions about what is possible in this unexpected “glitch” state. Well, so do we! We know that we can corrupt the system state badly enough to cause machine check errors, and we’ve also observed threads interfere with execution of processes scheduled on SMT siblings. However, we simply don’t know if we can control the corruption precisely enough to achieve privilege escalation. I suspect that it is possible, but we don’t have any way to debug μop execution! If you’re interested in studying this, then we would love to get your input! Credit This bug was independently discovered by multiple research teams within Google, including the silifuzz team and Google Information Security Engineering. The bug was analyzed by Tavis Ormandy, Josh Eads, Eduardo Vela Nava, Alexandra Sandulescu and Daniel Moghimi. Solution Intel have published updated microcode for all affected processors. Your operating system or BIOS vendor may already have an update available! Workaround If you can’t update for some reason, you could disable fast strings via the IA32_MISC_ENABLE model specific register. This will cause a significant performance penalty, and should not be used unless absolutely necessary. Notes If you’re interested in more CPU bugs, we publish everything we find! Not all the bugs we discover have security consequences, but they’re usually worth reading! For example, did you know that sometimes movlps just doesn’t work? or that registers can sometimes roll back to previous values? HOME • ABOUT • CONTACT

1 0

The women of my ideology fight alongside the men
by professor rat 15 Nov '23

15 Nov '23

Witness. The women of my ideology fight alongside the men https://anarchistnews.org/content/patacons-libertarian-band-prades-mountains Reposts not popgun, fart, counter-revolutionary, corporate crap from Bloomberg larceny dipshits in NYC

1 0

Fwd: Your Freedom of Information Law (FOIL) Request FOIL-2023-095358-020881DFS Investigation Finds Robinhood Crypto Failed to Maintain Effective and Compliant BSA/AML and Cybersecurity Programs
by Gunnar Larson 14 Nov '23

14 Nov '23

---------- Forwarded message --------- From: <Joanne.Verdejo(a)dfs.ny.gov> Date: Fri, Nov 3, 2023, 1:22 PM Subject: Your Freedom of Information Law (FOIL) Request FOIL-2023-095358-020881 To: <G(a)xny.io> Good afternoon, Attached please find correspondence from the NYS Department of Financial Services, pertaining to your FOIL request. Thank you. Tracking Number:FOIL-2023-095358-020881 Re: FOIL Tracking No. 2023-095358 Dear Gunnar Larson: I write with respect to your above-referenced FOIL request. The New York State Department of Financial Services (DFS) requires additional time to respond to your request, assigned the tracking number 2023-095358, because we are still processing your request. DFS intends to provide its determination of your request by December 22, 2023. We appreciate your continued patience. Thank you. ---------- Forwarded message --------- From: <noreply(a)its.ny.gov> Date: Tue, Jun 27, 2023, 6:52 PM Subject: FOIL Request Confirmation from Open FOIL NY To: <G(a)xny.io> Thank you for submitting your FOIL request through Open FOIL NY. Here is your Open FOIL NY confirmation information for future reference: LARSON_DFS_20230627185237536 INFORMATION SUBMITTED: Records Requested From Department of Financial Services Short Title DFS Investigation Finds Robinhood Crypto Failed to Maintain Effective and Compliant BSA/AML and Cybersecurity Programs Description Dear Madam or Sir: On August 2, 2022 the Superintendent of Financial Services Adrienne A. Harris announced that Robinhood Crypto, LLC (“RHC”) would pay a $30 million penalty to New York State for significant failures in the areas of bank secrecy act/anti-money laundering (“BSA/AML”) obligations and cybersecurity that resulted in violations of the Department’s Virtual Currency Regulation (23 NYCRR Part 200), Money Transmitter Regulation (3 NYCRR Part 417), Transaction Monitoring Regulation (23 NYCRR Part 504), and Cybersecurity Regulation (23 NYCRR Part 500). xNY.io - Bank.org would like to receive any and all records related to NY-DFS' investigation of Robinhood Crypto. Including (but not limited to) records concerning the bespoke Supervisory Agreement Robinhood Crypto has with the Department of Financial Services mentioned here: https://www.dfs.ny.gov/reports_and_publications/press_releases/pr202208021. In addition, xNY.io - Bank.org seeks any and all records concerning New York's approach to Robinhood Crypto and Goldman Sachs compliance programs mandated by the United States Department of Justice, Criminal Division, Fraud Section and Money Laundering and Asset Recovery Section mentioned here: https://drive.google.com/file/d/1Yx88RMoeLyyfbNK0RtPl4r-m8N21_1Sp/view?usp=…. Finally, xNY.io - Bank.org seeks records concerning New York's regulatory approval of Robinhood Crypto engaging a fine of $30M to implement heightened controls and additional procedures and policies relating to electronic surveillance and investigation, due diligence on transactions or clients and the use of third-party intermediaries across business units; and enhancing anti-corruption training for all management and relevant employees. Warm regards, Gunnar Larson xNY.io - Bank.org 917-580-8053 Uploaded Files FOIL Response Format Email If fees apply, please contact me if costs will be greater than $10000 Your FOIL request has been forwarded to the organization(s) you selected, and the respective Records Access Officer will contact you directly for further processing of your request. Please allow up to five business days for such communication(s). For your convenience, here is additional contact information: Department of Financial Services One State Street 20th Floor New York, NY 10004

1 0

Goldman Keeps Getting More Boring
by Gunnar Larson 14 Nov '23

14 Nov '23

Goldman Keeps Getting More Boring https://www.bloomberg.com/opinion/articles/2023-11-14/goldman-keeps-getting… At Business Insider, Bethany McLean writes about an unusual problem that afflicts her and me and a handful of other journalists, which is (disclosure!) that we used to work at Goldman Sachs Group Inc., and now we write about finance, and we try to be fair and thoughtful, but we still have some rooting interest in Goldman’s mystique.

1 0

Ghacks: Mullvad's public encrypted DNS Servers run in RAM now
by jdb10987＠yahoo.com 13 Nov '23

13 Nov '23

1 0

Brian Pak needs killing ( my 2k sats )
by pro2rat＠yahoo.com.au 13 Nov '23

13 Nov '23

Brian Pak is CEO & Co-Founder of ChainLight, an award-winning blockchain security firm that specializes in smart contract audits and on-chain monitoring. He is also a co-founder of Theori, an established US-based offensive cybersecurity company, since 2016, which he still leads today, having now amassed trusted partners including Microsoft, Google and Samsung. Brian’s early career started when he co-founded and developed Kaprica Security, inventing and patenting the Skorpion Charger, an Android mobile charger that can detect malicious software with no user action required. He has worked on research and development projects with the Defense Advanced Research Projects Agency (DARPA) of the US. Brian is also a founder of the team PPP (Plaid Parliament of Pwning) which won DEF CON CTF, one of the most prestigious hacker competitions held in Las Vegas, in 2013, 2014, 2016, 2017, 2019, 2022 and 2023. Brian graduated with a Masters Degree in Software Security Research from Carnegie Mellon University.

1 0

Fwd: [OpenRecords] Request FOIL-2023-836-00688 Extended
by Gunnar Larson 13 Nov '23

13 Nov '23

---------- Forwarded message --------- From: <donotreply(a)records.nyc.gov> Date: Tue, Oct 17, 2023, 2:52 PM Subject: [OpenRecords] Request FOIL-2023-836-00688 Extended To: <g(a)xny.io> The Department of Finance (DOF) has *extended* the time to respond to your FOIL request FOIL-2023-836-00688 <https://a860-openrecords.nyc.gov/request/view/FOIL-2023-836-00688> for the following reasons: You can expect a response on or about Friday, December 15, 2023. Additional Information: As indicated above, we are extending the time to respond because we are working on locating and compiling responsive records, after which we must subject records to legal review. Thank you for your continued patience. Please visit FOIL-2023-836-00688 <https://a860-openrecords.nyc.gov/request/view/FOIL-2023-836-00688> to view additional information and take any necessary action. ---------- Forwarded message --------- From: <donotreply(a)records.nyc.gov> Date: Fri, Jul 21, 2023, 10:22 AM Subject: [OpenRecords] Request FOIL-2023-836-00688 Acknowledged To: <g(a)xny.io> The Department of Finance (DOF) has acknowledged your FOIL request FOIL-2023-836-00688. You can expect a response on or about Tuesday, October 17, 2023. Additional Information: Hello, we are extending your request because our office needs more time to fulfill your request. We are finding and reviewing your requested records and you should hear from us by the date indicated above. We appreciate your patience as we subject each page of each record to legal review while processing other FOIL requests.Thank you for your continued patience. Please visit FOIL-2023-836-00688 to view additional information and take any necessary action. Your request FOIL-2023-836-00688 has been successfully submitted to the Department of Finance (DOF). The details of your request are shown below. Request Title: Mayor Eric Adams and Bitcoin Request Description: Dear Madam or Sir: Mayor Adams announced paychecks will automatically be converted into cryptocurrency via Coinbase, a secure online platform for buying, selling, transferring, and storing digital currency. https://www.nyc.gov/office-of-the-mayor/news/041-22/mayor-adams-receive-fir… xNY.io kindly requests access to records concerning the payment structure related to this payment vehicle. Additionally, we would like any records concerning the City’s due diligence of the online payment platform's compliance to New York State investigation. Thank you, Gunnar Larson 917-580-8053 Requester's Contact Information Name: Gunnar Larson Title: Not provided Organization: Not provided Email: g(a)xny.io Phone Number: Not provided Fax Number: Not provided Street Address (line 1): 406 West 25th Street Street Address (line 2): Not provided City: New York State: NY Zip Code: 10001 You can view the request and take any necessary action at the following webpage: https://a860-openrecords.nyc.gov/request/view/FOIL-2023-836-00688

1 0

Zeke Faux on Crypto and the Digital Asset Frenzy (Podcast)
by Gunnar Larson 12 Nov '23

12 Nov '23

Just listened to this. Really good. Highly recommend. ------ Zeke Faux on Crypto and the Digital Asset Frenzy (Podcast) https://www.bloomberg.com/news/audio/2023-11-02/zeke-faux-on-crypto-and-the…

1 0