An anonymous reader shares a report: In 2015, researchers reported a surprising discovery that stoked industry-wide security concerns -- an attack called RowHammer that could corrupt, modify, or steal sensitive data when a simple user-level application repeatedly accessed certain regions of DDR memory chips. In the coming years, memory chipmakers scrambled to develop defenses that prevented the attack, mainly by limiting the number of times programs could open and close the targeted chip regions in a given time. Recently, researchers devised a new method for creating the same types of RowHammer-induced bitflips even on a newer generation of chips, known as DDR4, that have the RowHammer mitigations built into them. Known as RowPress, the new attack works not by "hammering" carefully selected regions repeatedly, but instead by leaving them open for longer periods than normal. Bitflips refer to the phenomenon of bits represented as ones change to zeros and vice versa.

Further amplifying the vulnerability of DDR4 chips to read-disturbance attacks -- the generic term for inducing bitflips through abnormal accesses to memory chips -- RowPress bitflips can be enhanced by combining them with RowHammer accesses. Curiously, raising the temperature of the chip also intensifies the effect. "We demonstrate a proof of concept RowPress program that can cause bitflips in a real system that already employs protections against RowHammer," Onur Mutlu, a professor at ETH Zurich and a co-author of a recently published paper titled RowPress: Amplifying Read Disturbance in Modern DRAM Chips [PDF], wrote in an email. "Note that this is not in itself an attack. It simply shows that bitflips are possible and plenty, which can easily form the basis of an attack. As many prior works in security have shown, once you can induce a bitflip, you can use that bitflip for various attacks."

AlmaLinux is creating a Red Hat Enterprise Linux (RHEL) without any Red Hat code. Instead, AlmaLinux OS will aim to be Application Binary Interface (ABI) compatible and use the CentOS Stream source code that Red Hat continues to offer. Additional code is pulled from Red Hat Universal Base Images, and upstream Linux code. Benny Vasquez, chairperson of the AlmaLinux OF Foundation, explained how all this works at the open-source community convention All Things Open. ZDNet's Steven Vaughan-Nichols reports: The hardest part is Red Hat's Linux kernel updates because, added Vasquez, "you can't get those kernel updates without violating Red Hat's licensing agreements." Therefore, she continued, "What we do is we pull the security patches from various other sources, and, if nothing else, we can find them when Oracle releases them." Vasquez did note one blessing from this change in production: "AlmaLinux, no longer bound to Red Hat's releases, has been able to release upstream security fixes faster than Red Hat. "For example, the AMD microcode exploits were patched before Red Hat because they took a little bit of extra time to get out the door. We then pulled in, tested, and out the door about a week ahead of them." The overall goal remains to maintain RHEL compatibility. "Any breaking changes between RHEL and AlmaLinux, any application that stops working, is a bug and must be fixed."

That's not to say AlmaLinux will be simply an excellent RHEL clone going forward. It plans to add features of its own. For instance, Red Hat users who want programs not bundled in RHEL often turn to Extra Packages for Enterprise Linux (EPEL). These typically are programs included in Fedora Linux. Besides supporting EPEL software, AlmaLinux has its own extra software package -- called Synergy -- which holds programs that the AlmaLinux community wants but are not available in either EPEL or RHEL. If one such program is subsequently added to EPEL or RHEL, AlmaLinux drops it from Synergy to prevent confusion and duplication of effort.

This has not been an easy road for AlmaLinux. Even a 1% code difference is a lot to write and maintain. For example, when AlmaLinux tried to patch CentOS Stream code to fix a problem, Red Hat was downright grumpy about AlmaLinux's attempt to fix a security hole. Vasquez acknowledged it was tough sledding at first, but noted: "The good news is that they have been improving the process, and things will look a little bit smoother." AlmaLinux, she noted, is also not so much worried as aware that Red Hat may throw a monkey wrench into their efforts. Vasquez added: "Internally, we're working on stopgap things we'd need to do to anticipate Red Hat changing everything terribly." She doesn't think Red Hat will do it, but "we want to be as prepared as possible."

Google security researchers say they have found evidence that government-backed hackers linked to Russia and China are exploiting a since-patched vulnerability in WinRAR, the popular shareware archiving tool for Windows. From a report: The WinRAR vulnerability, first discovered by cybersecurity company Group-IB earlier this year and tracked as CVE-2023-38831, allows attackers to hide malicious scripts in archive files that masquerade as seemingly innocuous images or text documents. Group-IB said the flaw was exploited as a zero-day -- since the developer had zero time to fix the bug before it was exploited -- as far back as April to compromise the devices of at least 130 traders.

Rarlab, which makes the archiving tool, released an updated version of WinRAR (version 6.23) on August 2 to patch the vulnerability. Despite this, Google's Threat Analysis Group (TAG) said this week that its researchers have observed multiple government-backed hacking groups exploiting the security flaw, noting that "many users" who have not updated the app remain vulnerable. In research shared with TechCrunch ahead of its publication, TAG says it has observed multiple campaigns exploiting the WinRAR zero-day bug, which it has tied to state-backed hacking groups with links to Russia and China.

ZDNet's senior contributing editor also maintains software, and recently tested ChatGPT on two fixes for bugs reported by users, and a new piece of code to add a new feature, It's a "real-world" coding test, "about pulling another customer support ticket off the stack and working through what made the user's experience go south." First...

please rewrite the following code to change it from allowing only integers to allowing dollars and cents (in other words, a decimal point and up to two digits after the decimal point). ChatGPT responded by explaining a two-step fix, posting the modified code, and then explaining the changes. "I dropped ChatGPT's code into my function, and it worked. Instead of about two-to-four hours of hair-pulling, it took about five minutes to come up with the prompt and get an answer from ChatGPT." Next up was reformatting an array. I like doing array code, but it's also tedious. So, I once again tried ChatGPT. This time the result was a total failure. By the time I was done, I probably fed it 10 different prompts. Some responses looked promising, but when I tried to run the code, it errored out. Some code crashed; some code generated error codes. And some code ran, but didn't do what I wanted. After about an hour, I gave up and went back to my normal technique of digging through GitHub and StackExchange to see if there were any examples of what I was trying to do, and then writing my own code.
Then he posted the code for a function handling a Wordpress filter, along with the question: "I get the following error. Why?" Within seconds, ChatGPT responded... Just as it suggested, I updated the fourth parameter of the add_filter() function to 2, and it worked!

ChatGPT took segments of code, analyzed those segments, and provided me with a diagnosis. To be clear, in order for it to make its recommendation, it needed to understand the internals of how WordPress handles hooks (that's what the add_filter function does), and how that functionality translates to the behavior of the calling and the execution of lines of code. I have to mark that achievement as incredible — undeniably 'living in the future' incredible...

As a test, I also tried asking ChatGPT to diagnose my problem in a prompt where I didn't include the handler line, and it wasn't able to help. So, there are very definite limitations to what ChatGPT can do for debugging right now, in 2023...

Could I have fixed the bug on my own? Of course. I've never had a bug I couldn't fix. But whether it would have taken two hours or two days (plus pizza, profanity, and lots of caffeine), while enduring many interruptions, that's something I don't know. I can tell you ChatGPT fixed it in minutes, saving me untold time and frustration.
The article does include a warning. "AI is essentially a black box, you're not able to see what process the AI undertakes to come to its conclusions. As such, you're not really able to check its work... If it turns out there is a problem in the AI-generated code, the cost and time it takes to fix may prove to be far greater than if a human coder had done the full task by hand."

But it also ends with this prediction. "I see a very interesting future, where it will be possible to feed ChatGPT all 153,000 lines of code and ask it to tell you what to fix... I can definitely see a future where programmers can simply ask ChatGPT (or a Microsoft-branded equivalent) to find and fix bugs in entire projects."

T2 SDE is not just a Linux distribution, but "a flexible Open Source System Development Environment or Distribution Build Kit," according to a 2022 announcement of its support for 25 CPU architectures, variants, and C libraries. ("Others might even name it Meta Distribution. T2 allows the creation of custom distributions with state of the art technology, up-to-date packages and integrated support for cross compilation.")

And while working on it, Berlin-based T2 Linux developer René Rebe (long-time Slashdot reader ReneR) discovered random illegal instruction speculation on AMD Ryzen 7000-Series and Epyc Zen 4 CPU.

ReneR writes: Merged to Linux 6.6 Git is a fix for the bug now known at AMD as Erratum 1485.

The discovery was possible through continued high CPU load cross-compiling the T2 Linux distribution with support for all CPU architectures from ARM, MIPS, PowerPC, RISC-V to x86 (and more) for 33 build variants. With sustained high CPU load and various instruction sequences being compiled, pseudo random illegal instruction errors were observed and subsequently analyzed.

ExactCODE Research GmbH CTO René Rebe is thrilled that working with AMD engineers lead to a timely mitigation to increase system stability of the still new and highest performance Zen4 platform.
"I found real-world code that might be similar or actually trigger the same bugs in the CPU that are also used for all the Spectre Meltdown and other side-channel security vulnerability mitigations," Rebe says in a video announcement on YouTube.

It took Rebe a tremendous amount of research, and he says now that "all the excessive work changed my mind. Mitigations equals considered harmful... If you want stable, reliable computational results — no, you can't do this. Because as Spectre Meltdown and all the other security issues have proven, the CPUs are nowadays as complex as complex software systems..."

Microsoft says Chinese state-backed hackers are exploiting a "critical"-rated zero-day vulnerability in Atlassian software to break into customer systems. From a report: The technology giant's threat intelligence team said in a post on X, formerly Twitter, that it has observed a nation-state threat actor it calls Storm-0062 exploiting a recently disclosed critical flaw in Atlassian Confluence Data Center and Server. Microsoft has previously identified Storm-0062 as a China-based state-sponsored hacker.

Microsoft said it observed in-the-wild abuse of the maximum rated 10.0 vulnerability, tracked as CVE-2023-22515, since September 14, some three weeks before Atlassian's public disclosure on October 4. A bug is considered a zero-day when the vendor -- in this case Atlassian -- has zero time to fix the bug before it is exploited. Atlassian updated its advisory this week to confirm it has "evidence to suggest that a known nation-state actor" is exploiting the bug, which the company says could allow a remote attacker to create unauthorized administrator accounts to access Confluence servers. Atlassian's Confluence is a widely popular collaborative wiki system used by corporations around the world to organize and share work.

Apple rolled out a software update Wednesday to address an overheating issue that plagued some early buyers of the iPhone 15 Pro line. From a report: The update, called iOS 17.0.3, is available as an over-the-air fix in the software update section of the iPhone settings app. The release notes say the update "provides important bug fixes, security updates, and addresses an issue that may cause iPhone to run warmer than expected." The update was also released for older iPhones as well as iPads. Some early iPhone 15 Pro owners reported that their iPhone could get hotter than normal. Apple on Saturday blamed bad code in apps including Uber, Instagram and the Asphalt 9 racing game, in addition to a bug in the device's software. The company said the new device set-up could overwork the processor and lead to overheating.

An anonymous reader shared this report from CNBC: Apple said on Saturday that it will issue a software update that would address customer complaints about the latest iPhone 15 models, released just over a week ago, running hot.

Apple said that the new iPhone models were running hot because of a combination of bugs in iOS 17, bugs in apps, and a temporary set-up period... After Apple released the new iPhone 15 models earlier this month, user complaints on Apple's forums, Reddit, and social media suggest that all four models can get hotter than expected during use. CNBC's review of the new iPhone Pros also noted the iPhone 15 Pro Max got hot. "I just got the iPhone 15 Pro today and it's so hot i can't even hold it for very long!" wrote one commenter on Apple's forums.

Apple's new high-end models, the $999 iPhone 15 Pro and $1,199 iPhone 15 Pro Max have a redesigned titanium enclosure with an aluminum frame to make them easier to repair. The problem with the new models overheating was not related to the titanium chassis design, Apple said. Instead, Apple points to bugs with specific apps and a bug in iOS that can be fixed with software updates.

Kyle Orland writes via Ars Technica: The "first official Unity user group in the world" has announced that it is dissolving after 13 years because "the trust we used to have in the company has been completely eroded." The move comes as many developers are saying they will continue to stay away from the company's products even after last week's partial rollback of some of the most controversial parts of its fee structure plans.

Since its founding in 2010, the Boston Unity Group (BUG) has attracted thousands of members to regular gatherings, talks, and networking events, including many technical lectures archived on YouTube. But the group says it will be hosting its last meeting Wednesday evening via Zoom because the Unity of today is very different from the Dave Helgason-led company that BUG says "enthusiastically sanctioned and supported" the group at its founding.

"Over the past few years, Unity has unfortunately shifted its focus away from the games industry and away from supporting developer communities," the group leadership wrote in a departure note. "Following the IPO, the company has seemingly put profit over all else, with several acquisitions and layoffs of core personnel. Many key systems that developers need are still left in a confusing and often incomplete state, with the messaging that advertising and revenue matter more to Unity than the functionality game developers care about."

BUG says the install-fee terms Unity first announced earlier this month were "unthinkably hostile" to users and that even the "new concessions" in an updated pricing model offered late last week "disproportionately affect the success of indie studios in our community." But it's the fact that such "resounding, unequivocal condemnation from the games industry" was necessary to get those changes in the first place that has really shaken the community to its core. "We've seen how easily and flippantly an executive-led business decision can risk bankrupting the studios we've worked so hard to build, threaten our livelihoods as professionals, and challenge the longevity of our industry," BUG wrote. "The Unity of today isn't the same company that it was when the group was founded, and the trust we used to have in the company has been completely eroded."

An exploit for a bug in Windows appears to increase the performance of File Explorer in Microsoft's flagship operating system. From a report: Spotted over the weekend by Xitter user @VivyVCCS, the hack is triggered by a swift jab of the F11 key to switch File Explorer in and out of full-screen mode. According to the post, load performance is improved markedly.

Slash_Account_Dot writes: Hackers are able to grab a target's IP address, potentially revealing their general physical location, by simply sending a link over the Skype mobile app. The target does not need to click the link or otherwise interact with the hacker beyond opening the message, according to a security researcher who demonstrated the issue and successfully discovered my IP address by using it. Yossi, the independent security researcher who uncovered the vulnerability, reported the issue to Microsoft earlier this month, according to Yossi and a cache of emails and bug reports he shared with 404 Media. In those emails Microsoft said the issue does not require immediate servicing, and gave no indication that it plans to fix the security hole. Only after 404 Media contacted Microsoft for comment did the company say it would patch the issue in an upcoming update.

This month the official Rust blog announced: For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust. This edition of the annual State of Rust Survey opened for submissions on December 5 and ran until December 22, 2022... [W]e had 9,433 total survey completions and an increased survey completion rate of 82% vs. 76% in 2021...

- More people are using Rust than ever before! Over 90% of survey respondents identified as Rust users, and of those using Rust, 47% do so on a daily basis — an increase of 4% from the previous year.

- 30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust. Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.

- The growing maturation of Rust can be seen through the increased number of different organizations utilizing the language in 2022. In fact, 29.7% of respondents stated that they use Rust for the majority of their coding work at their workplace, which is a 51.8% increase compared to the previous year.

- There are numerous reasons why we are seeing increased use of Rust in professional environments. Top reasons cited for the use of Rust include the perceived ability to write "bug-free software" (86%), Rust's performance characteristics (84%), and Rust's security and safety guarantees (69%). We were also pleased to find that 76% of respondents continue to use Rust simply because they found it fun and enjoyable. (Respondents could select more than one option here, so the numbers don't add up to 100%.)

- Of those respondents that used Rust at work, 72% reported that it helped their team achieve its goals (a 4% increase from the previous year) and 75% have plans to continue using it on their teams in the future.

- But like any language being applied in the workplace, Rust's learning curve is an important consideration; 39% of respondents using Rust in a professional capacity reported the process as "challenging" and 9% of respondents said that adopting Rust at work has "slowed down their team". However, 60% of productive users felt Rust was worth the cost of adoption overall...

- Of those respondents who shared their main worries for the future of Rust, 26% have concerns that the developers and maintainers behind Rust are not properly supported — a decrease of more than 30% from the previous year's findings. One area of focus in the future may be to see how the Project in conjunction with the Rust Foundation can continue to push that number towards 0%.

- While 38% have concerns about Rust "becoming too complex", only a small number of respondents were concerned about documentation, corporate oversight, or speed of evolution. 34% of respondents are not worried about the future of Rust at all.

This year's survey reflects a 21% decrease in fears about Rust's usage in the industry since the last survey.

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

"Teams across Google are working hard to prepare the web for the migration to quantum-resistant cryptography," writes Chrome's technical program manager for security, Devon O'Brien.

"Continuing with our strategy for handling this major transition, we are updating technical standards, testing and deploying new quantum-resistant algorithms, and working with the broader ecosystem to help ensure this effort is a success." As a step down this path, Chrome will begin supporting X25519Kyber768 for establishing symmetric secrets in TLS, starting in Chrome 116, and available behind a flag in Chrome 115. This hybrid mechanism combines the output of two cryptographic algorithms to create the session key used to encrypt the bulk of the TLS connection:

X25519 — an elliptic curve algorithm widely used for key agreement in TLS today
Kyber-768 — a quantum-resistant Key Encapsulation Method, and NIST's PQC winner for general encryption

In order to identify ecosystem incompatibilities with this change, we are rolling this out to Chrome and to Google servers, over both TCP and QUIC and monitoring for possible compatibility issues. Chrome may also use this updated key agreement when connecting to third-party server operators, such as Cloudflare, as they add support. If you are a developer or administrator experiencing an issue that you believe is caused by this change, please file a bug.
The Register delves into Chrome's reasons for implementing this now: "It's believed that quantum computers that can break modern classical cryptography won't arrive for 5, 10, possibly even 50 years from now, so why is it important to start protecting traffic today?" said O'Brien. "The answer is that certain uses of cryptography are vulnerable to a type of attack called Harvest Now, Decrypt Later, in which data is collected and stored today and later decrypted once cryptanalysis improves." O'Brien says that while symmetric encryption algorithms used to defend data traveling on networks are considered safe from quantum cryptanalysis, the way the keys get negotiated is not. By adding support for a hybrid KEM, Chrome should provide a stronger defense against future quantum attacks...

Rebecca Krauthamer, co-founder and chief product officer at QuSecure, told The Register in an email that while this technology sounds futuristic, it's useful and necessary today... [T]he arrival of capable quantum computers should not be thought of as a specific, looming date, but as something that will arrive without warning. "There was no press release when the team at Bletchley Park cracked the Enigma code, either," she said.

Google announced today that Chrome is now adopting weekly Stable channel updates in an effort to block major exploits quicker. 9to5Google reports: Google's browser gets major "milestone" updates every four (previously six) weeks, like going from version 100 to 101. In the past, Chrome would get a "Stable Refresh" update to "address security and other high impact bugs" in-between milestones every two weeks. This is now changing to occur weekly between milestones, starting with Google Chrome 116 on desktop and mobile, so that security updates get to end users much faster. Since Chromium is an open source project, "anyone can view the source code, submit changes for review, and see the changes made by anyone else, even security bug fixes." [...]

The current patch gap is around 15 days. It was previously 35 days before switching to patch updates every two weeks in 2020. Google expects weekly patch updates to result in security fixes shipping "3.5 days sooner on average, greatly reducing the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult." This new schedule will also result in fewer unplanned updates that occur when there are known in-the-wild exploits: "By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we'll be shipping updates more frequently."

In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

An anonymous reader quotes a report from Wired: Travel rewards programslike those offered by airlines and hotels tout the specific perks of joining their club over others. Under the hood, though, the digital infrastructure for many of these programs -- including Delta SkyMiles, United MileagePlus, Hilton Honors, and Marriott Bonvoy -- is built on the same platform. The backend comes from the loyalty commerce company Points and its suite of services, including an expansive application programming interface (API).But new findings, published today by a group of security researchers, show that vulnerabilities in the Points.com API could have been exploited to expose customer data, steal customers' "loyalty currency" (like miles), or even compromise Points global administration accounts to gain control of entire loyalty programs. The researchers -- Ian Carroll, Shubham Shah, and Sam Curry -- reported a series of vulnerabilities to Points between March and May, and all the bugs have since been fixed.

"The surprise for me was related to the fact that there is a central entity for loyalty and points systems, which almost every big brand in the world uses," Shah says. "From this point, it was clear to me that finding flaws in this system would have a cascading effect to every company utilizing their loyalty backend. I believe that once other hackers realized that targeting Points meant that they could potentially have unlimited points on loyalty systems, they would have also been successful in targeting Points.com eventually." One bug involved a manipulation that allowed the researchers to traverse from one part of the Points API infrastructure to another internal portion and then query it for reward program customer orders. The system included 22 million order records, which contain data like customer rewards account numbers, addresses, phone numbers, email addresses, and partial credit card numbers. Points.com had limits in place on how many responses the system could return at a time, meaning an attacker couldn't simply dump the whole data trove at once. But the researchers note that it would have been possible to look up specific individuals of interest or slowly siphon data from the system over time.

Another bug the researchers found was an API configuration issue that could have allowed an attacker to generate an account authorization token for any user with just their last name and rewards number. These two pieces of data could potentially be found through past breaches or could be taken by exploiting the first vulnerability. With this token, attackers could take over customer accounts and transfer miles or other rewards points to themselves, draining the victim's accounts. The researchers found two vulnerabilities similar to the other pair of bugs, one of which only impacted Virgin Red while the other affected just United MileagePlus. Points.com fixed both of these vulnerabilities as well. Most significantly, the researchers found a vulnerability in the Points.com global administration website in which an encrypted cookie assigned to each user had been encrypted with an easily guessable secret -- the word "secret" itself. By guessing this, the researchers could decrypt their cookie, reassign themselves global administrator privileges for the site, reencrypt the cookie, and essentially assume god-mode-like capabilities to access any Points reward system and even grant accounts unlimited miles or other benefits.

Long-time Slashdot reader SonicSpike shares a report from CNBC: On Tuesday, the Biden administration put the final nail in the coffin for incandescent light bulbs, the result of a decade-plus-long legislative path. The journey began in 2007 when the Energy Independence and Security Act passed. That law required the Department of Energy to evaluate whether efficiency standards for light bulbs needed to be set or amended and required a minimum standard of energy efficiency for light bulbs of 45 lumens per watt to be considered. The 2007 law required that if the DOE determined a new energy efficiency standard was necessary, it should go into effect by January 1, 2017. But politics intervened as the Trump administration appealed those rules.

The Biden administration picked the issue back up. And in April 2022, the Biden administration issued a rule requiring the minimum standard efficiency of 45 lumens per watt, which became effective in July. At that time, the Department of Energy said it would have a gradual transition to the new rule so that stores with inventory would not be stuck with light bulbs they could no longer sell. In Department of Energy lingo, this is called "progressive enforcement." Full enforcement of the ban for retailers took effect on Tuesday. The DOE does not disclose its techniques for enforcing these step-wise implementation of the rule. However, the agency's new regulations will be enforced in "a fair and equitable manner," and smaller retailers are advised to reach out to the DOE to speak about existing inventory they may still have on hand, a spokesperson told CNBC.

Enforcing the sale of the more energy-efficient light bulbs will save consumers nearly $3 billion per year on their utility bills, according to DOE estimates, and cut carbon emissions by 222 million metric tons over the next 30 years. That's about the quantity of emissions that 28 million homes generate in a year, the Department of Energy said. [...] Not all light bulbs are included in the ban. Exceptions include a whole slew of specific light bulb implications, including appliance lamps, black light lamps, bug lamps, colored lamps, general service fluorescent lamps, marine lamps, marine signal service lamps, mine service lamps, sliver bowl lamps, showcase lamps, and traffic signal lamp, to name a few.

An anonymous reader shares a report: When Microsoft releases new test builds of Windows, there are usually a handful of features that are announced but only actually enabled for a small subset of testers. Sometimes it's because the company is A/B testing a couple of different versions of the same thing or because Microsoft wants to roll out major changes to a few users before rolling them out to everyone. Users normally have little control over whether new features actually appear in their Windows beta installs, but Microsoft has internal software called StagingTool that its own developers can use to switch things on and off themselves.

And now StagingTool has leaked to the public, thanks to a "bug bash" the company is running this week to find and fix problems before the next big batch of new Windows features releases this fall. As reported by The Verge, some bug bash participants were sent on "quests" that explicitly mentioned using the StagingTool to turn on specific features. Those quests and the tool itself have since been removed from Microsoft's servers, but StagingTool is already being freely distributed among Windows enthusiasts who want more control over the features they see.

Apple's Screen Time controls are failing parents. From a report: The company's cloud-based Family Sharing system is designed in part for parents to remotely schedule off-limits time and restrict apps and adult content on their children's iPhones, iPads and iPod Touch models. Trouble is, parents are finding that when they use their iPhones to set restrictions on their kids' devices, the changes don't stick. "We are aware that some users may be experiencing an issue where Screen Time settings are unexpectedly reset," an Apple spokeswoman said. "We take these reports very seriously and we have been, and will continue, making updates to improve the situation."

Downtime, found in Settings under Screen Time, is the tool parents use to define the hours each day that a kid's device is limited or completely unusable. But when they check the setting lately, they often see the times they scheduled have reverted to a previous setting, or they see no restrictions at all. This can go unnoticed for days or weeks -- and kids don't always report back when they get extra time for games and social media. Apple previously acknowledged the bug, calling it "an issue where Screen Time settings may reset or not sync across all devices." However, the company had reported the issue fixed with iOS 16.5, which came out in May. In our testing the bug persists, even with the new public beta of iOS 17.