Information Technology

Russian hackers are still launching offensive cyber attacks against the US and its allies in efforts to steal information or lay the foundations for future operations, a joint alert by security and intelligence agencies has warned.The advisory from the FBI, Department of Homeland Security and CISA warns that the Russian Foreign Intelligence Service (SVR) – also known by cybersecurity researchers as APT 29, the Dukes and CozyBear – continues to target organisations in efforts to gather intelligence.US agencies – along with the UK’s National Cyber Security Centre (NCSC) – recently blamed the SVR for the SolarWinds supply chain attack, which saw hackers gain access to tens of thousands of organisations around the world – including several government agencies after compromising the company’s software updates process. And now organisations are being warned that Russian cyber attacks show no signs of slowing down, especially when it comes to targeting the networks of organisations involved with government, think tanks and information technology.Cloud services including email and Microsoft Office 365 are being particularly targeted in attacks.”Targeting cloud resources probably reduces the likelihood of detection by using compromised accounts or system misconfigurations to blend in with normal or unmonitored traffic in an environment not well defended, monitored, or understood by victim organizations,” warned the agency alert.SEE: Can Russian hackers be stopped? Here’s why it might take 20 years

The alert details common techniques used in SVR operations, including password spraying, leveraging zero-day vulnerabilities and deploying malware.Password spraying is when the attackers target weak passwords associated with admin accounts. These accounts are secured with common or weak passwords, including default usernames and passwords, providing cyber attackers with a relatively simple means of gaining access to poorly secured networks. In many cases, the attackers will break into as many accounts as they can, only thinking about how they can be exploited later.To defend against password spraying attacks, the FBI and DHS recommend the mandatory use of multi-factor authentication across the network and to where possible, enforce the use of strong passwords – particularly for administrator accounts. It’s also recommended that access to remote administrative functions from IP addresses not owned by the organisations is prohibited.Another common attack technique used by Kremlin-backed hackers is levering vulnerabilities in virtual private network (VPN) appliances which expose login credentials.The alert uses the example of attackers exploiting CVE-2019-19781 – a vulnerability in Citrix Application Delivery Controller and Gateway – but it’s one of several which have been exploited in cyber attacks in recent years, allowing attackers to secretly enter networks.In each of these cases, the affected vendor has released a critical security patch – and in some cases these have been available for years – but organisations which don’t apply the updates are still vulnerable to attacks. The FBI, DoH and CISA also warn about attacks using WellMess – a form of custom malware associated with APT 29, which has been used in attacks targeting Covid-19 vaccine research facilities. While stolen RDP credentials have been used to help install the malware, it’s also been known for attackers to attempt to distribute it via spear-phishing emails.The alert on Russian hacking techniques has been released in order to encourage organisations to examine their networks and gain a better understanding of how to secure against attacks.”The FBI and DHS are providing information on the SVR’s cyber tools, targets, techniques, and capabilities to aid organizations in conducting their own investigations and securing their networks,” said the alert.MORE ON CYBERSECURITY More

No one disputes that when things get back to normal, it’s going to be a whole new normal. For one thing, hybrid models are predicted to be the future for work and school. While it may be fun and exciting to work or take classes anywhere wifi is available, public wifi is notoriously insecure, so it is vital to get all the protection you can. Fortunately, Private Internet Access VPN provides everything you need to stay secure and more.

Protecting your data should always come first, and Private Internet Access will encrypt your data, as well as block malware, trackers, and ads with its new MACE feature. But this VPN will also allow you to browse online while remaining completely anonymous. The company’s no-logs policy is extremely strict, plus your IP address and location are always masked.In addition to privacy and security, an added perk to having Private Internet Access VPN is being able to access content from anywhere in the world, even though it is supposed to be restricted from the location where you happen to be. Of course, there are other VPNs who might advertise the same service, but Private Internet Access VPN excels at the way it executes those services.For instance, you don’t have to sacrifice internet speed for security, because Private Internet Access VPN has a lightning-fast global server network of over 35,000 servers in more than 77 countries, so you can access the content you want at the fastest possible speeds. The company also offers a simple, yet robust, intuitive user experience and 24/7 live customer support.It’s no wonder that Private Internet Access VPN has more than 30 million downloads, with 4.7 out of 5 stars on Apple’s App Store and 4.5 out of 5 stars on the Google Play Store. The service has also garnered numerous awards. It was named one of the Best VPN Services of 2021 by CNET, Editor’s Choice of PCMag.com and Tom’s Guide, and more.A two-year subscription to Private Internet Access VPN is currently being offered at a 72% discount off the regular price of $258, so you can get one today for only $69.95.

ZDNet Recommends More

The average ransom payment paid by victims of ransomware attacks has risen as cyber criminals exploit vulnerabilities in software and remote desktop protocol (RDP) services as common means of infiltrating networks.According to analysis by cybersecurity company Coveware’s Quarterly Ransomware Report, the average ransom payment in the first three months of this year was $220,298 – up from $154,108 in the final three months of 2020.

One of the reasons the cost of ransom payments has grown so significantly is a rise in activity by some of the most notorious ransom groups, which demand millions of dollars in Bitcoin from victims in exchange for the decryption key.SEE: A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)  This includes the Clop ransomware gang, which Coveware describes as “extremely active” in attacks targeting large victims and demanding very high ransom demands. It ranks at number four in the most common ransomware variants, accounting for 7% of all attacks even though it wasn’t in the top 10 at all during the previous quarter.The most common ransomware is Sodinokibi, which accounts for 14% of attacks, followed by Conti, which is behind 10% of ransomware attacks, and Lockbit, which is the third most common ransomware, with a 7.5% market share. Egregor is the fifth most common ransomware seen in the first quarter of 2020, accounting for 5.3% of attacks.Other ransomware variants commonly used in attacks at the moment include Avaddon, Ryuk, Darkside, Suncrypt, Netwalker, and Phobos.

One technique that is helping to make ransomware attacks more successful is for cyber criminals to publish data they’ve stolen while inside the network. The idea is that victims fear the consequences of potentially sensitive information being exposed online – so give in and pay the ransom. According to analysis by Coveware, 77% of ransomware attacks now involve a threat to leak exfiltrated data – up 10% compared with the final quarter of 2020.Almost half of ransomware attacks begin with cyber criminals compromising RDP services, either by using stolen credentials, guessing default or common passwords or by exploiting unpatched vulnerabilities. There’s also been a rise in software vulnerabilities being exploited as a means of infiltrating networks, particularly when it comes to those in VPN applications.SEE: Hackers are actively targeting flaws in these VPN devices. Here’s what you need to doAll of this has come together to result in an average of 23 days downtime following a ransomware attack – up by two days.Something that can help organisations successfully recover from a ransomware attack is regularly updating backups of the network – and storing them offline – so if the worst happens, restoring the network is possible without giving in to ransom demands, making the exercise a pointless waste of time for cyber criminals.But the best way to avoid damage from a ransomware attack is to avoid falling victim to one in the first place. Cybersecurity procedures that can help prevent this include avoiding the use of default usernames and passwords while also securing accounts with multi-factor authentication.Organisations should also ensure the latest security patches are applied to software across the network, preventing cyber criminals from being able to exploit known vulnerabilities to plant ransomware attacks. MORE ON CYBERSECURITY More

Adobe has released a “one-stop shop” project for data processing to the open source community. 

Adobe’s One-Stop Anomaly Shop (OSAS), now available on GitHub, has been developed to make the detection of abnormalities in datasets easier, as well as to improve the processing and format of security log data. According to Chris Parkerson, Adobe Corporate Security Team marketing lead, OSAS combines the vendor’s past security research and other open source projects to offer an ‘out of the box’ system for dataset experimentation, processing, and to allow developers to explore ways to “shorten the path to finding a balanced solution for detecting security threats.” This includes leveraging Hubble, an open source compliance monitoring tool. Security logs can be complicated and messy and may not fit well with machine learning (ML)-based analysis tools, creating data sparsity and problems in turning unstructured data into structured, usable sets.  The command-line interface (CLI) toolset applies two processes to datasets to try and make sense of security logs. The first is the tagging of raw data with field types such as “multinomial, text, and numeric values,” Parkerson says, and it is also possible to label content based on set rules.  During the second stage, the labels are used as input features for generic (unsupervised) or targeted (supervised) ML algorithms. At present there are three standard options, but more are planned for the future. 

Adobe has released the OSAS code in full and has also provided a Docker version.  Previous and related coverage Have a tip? Get in touch securely via WhatsApp | Signal at +447713 025 499, or over at Keybase: charlie0 More

UnitingCare Queensland has confirmed it has fallen victim to a cyber incident, rendering some of its systems inaccessible.The organisation, which provides aged care, disability supports, health care, and crisis response services throughout the state, said the incident occurred on Sunday 25 April 2021.”As a result of this incident, some of the organisation’s digital and technology systems are currently inaccessible,” it said in a statement.”As soon as we became aware of the incident, we engaged the support of lead external technical and forensic advisors.”UnitingCare also notified the Australian Cyber Security Centre (ACSC) of the incident and said it was continuing to work with them to investigate the incident.It said where necessary, manual back-up processes are in place to ensure continuity of most of UnitingCare’s services. “Where manual processes cannot be implemented, services are being redirected or rescheduled accordingly,” it added.

The organisation said that given the incident only occurred this week, it isn’t currently possible to provide a resolution timeframe. It said, however, its digital and technology team are working to resolve things as swiftly as possible.”We are committed to keeping our people, patients, clients, and residents informed and safe as we work to resolve this incident, and will provide further relevant updates as new information comes to hand,” the statement continued.Last year, the ACSC issued an alert to aged care and healthcare providers, notifying them of recent ransomware campaigns targeting the sector. “Cybercriminals view the aged care and healthcare sectors as lucrative targets for ransomware attacks,” the ACSC wrote. “This is because of the sensitive personal and medical information they hold, and how critical this information is to maintaining operations and patient care. A significant ransomware attack against a hospital or aged care facility would have a major impact.”Last month, a “cyber incident” suffered by Eastern Health facilities in Victoria resulted in the cancellation of some surgeries across the state.Eastern Health operates the Angliss, Box Hill, Healesville, and Maroondah hospitals, and has many more facilities under management.At the time, Eastern Health took many of its systems offline as a precaution response to the incident. By April 15, it reported the majority of its IT systems were restored.Swinburne University of Technology in early April also confirmed personal information on staff, students, and external parties had inadvertently made its way into the wild; and Transport for New South Wales (TfNSW) confirmed in February it was impacted by a cyber attack on a file transfer system owned by Accellion.  Need to disclose a breach? Read this: Notifiable Data Breaches scheme: Getting ready to disclose a data breach in AustraliaTELEHEALTH GETS BUDGET BOOSTElsewhere in the health sector, the Australian government on Monday confirmed telehealth services put in place as a response to COVID-19 would continue for another six months.As part of the 2021-22 Budget, the government said it would be investing more than AU$114 million to extend telehealth until the end of the year. The extension of telehealth includes services for general practitioners, medical practitioners, specialists, consultant physicians, nurse practitioners, participating midwives, allied health providers, and dental practitioners.”The extension will ensure that Australians can continue to see their GP, renew scripts, and seek mental health support from the safety of their own home,” Health Minister Greg Hunt said. “This allows vulnerable Australians to feel protected and supported during these unprecedented times.”From 13 March 2020 to 21 April 2021, Hunt said over 56 million COVID-19 Medicare Benefits Scheme telehealth services have been delivered to 13.6 million patients, with AU$2.9 billion in Medicare benefits paid. More than 83,540 providers have used telehealth services.Although content with the extension, Labor has asked for further permanency. “Greg Hunt said last November that telehealth will become a permanent feature of our Medicare system yet all he does is on a six month by six month basis is extend the uncertainty,” Shadow Minister for Health Mark Butler said.”It is time for the government finally to make a decision about what the permanent telehealth arrangements are going to be for Medicare.”RELATED COVERAGE More

Image: Getty Images/iStockphoto
Proofpoint has entered into an agreement with Thoma Bravo that will see the cybersecurity company become a wholly owned entity of the private equity firm.Thoma Bravo has agreed to spend around $12.3 billion on the acquisition.Under the terms of the all-cash agreement, Proofpoint shareholders will receive $176 per share. The company said this represents a premium of approximately 34% over Proofpoint’s closing share price on 23 April 2021.”Upon completion of the transaction, Proofpoint will become a private company with the flexibility and resources to continue providing the most effective cybersecurity and compliance solutions to protect people and organisations around the world,” the company said in a statement. “Additionally, Proofpoint will benefit from the operating capabilities, capital support, and deep sector expertise of Thoma Bravo — one of the most experienced and successful software investors in the world.”Thoma Bravo is no stranger to the tech market. The firm has acquired a sizable portfolio of technology brands, including Qlik, Flexera, Riverbed, Blue Coat, and Barracuda Networks. Thoma Bravo has also built a portfolio of security brands with the acquisitions of Sophos, Veracode, ConnectWise, and Imperva, as well as automotive software company Autodata. Last month, Thoma Bravo announced it was adding data integration provider Talend for $2.4 billion. Talend, which went public in 2016, said the deal will position the company for long-term growth and provide the necessary capital and resources to execute its market strategy. 

In 2020, Proofpoint generated more than $1 billion in annual revenue, a milestone the company’s chairman and CEO Gary Steele said made it the first SaaS-based cybersecurity and compliance company to do so.”We believe that as a private company, we can be even more agile with greater flexibility to continue investing in innovation, building on our leadership position, and staying ahead of threat actors,” Steele said. See also: Proofpoint sues Facebook to get permission to use lookalike domains for phishing testsProofpoint’s board of directors unanimously approved the agreement.The agreement includes a 45-day “go-shop” period expiring on 9 June 2021, which allows the board and its advisors to actively initiate, solicit, and consider alternative acquisition proposals from third parties, Proofpoint said. The transaction is expected to close in the third quarter of 2021, subject to customary closing conditions, including approval by Proofpoint shareholders and receipt of regulatory approvals. Proofpoint will also continue to be headquartered in Sunnyvale, California.The announcement was made on the same day the company’s first quarter results were released.Net loss for the three months to March 31 was $45.3 million. Total revenue for the first quarter of 2021 was $287.8 million, an increase of 15%, compared to the $249.8 million reported for the first quarter of 2020.GAAP gross profit for the first quarter of 2021 was $214.3 million, up from the $180.8 million reported a year prior. Non-GAAP gross profit was $232 million.  More

To say that Linux kernel developers are livid about a pair of University of Minnesota (UMN) graduate students playing at inserting security vulnerabilities into the Linux kernel for the purposes of a research paper “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits” is a gross understatement. Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch and well-known for being the most generous and easy-going of the Linux kernel maintainers, exploded and banned UMN developers from working on the Linux kernel. That was because their patches had been “obviously submitted in bad faith with the intent to cause problems.” The researchers, Qiushi Wu and Aditya Pakki, and their graduate advisor, Kangjie Lu, an assistant professor in the UMN Computer Science & Engineering Department of the UMN then apologized for their Linux kernel blunders. That’s not enough. The Linux kernel developers and the Linux Foundation’s Technical Advisory Board via the Linux Foundation have asked UMN to take specific actions before their people will be allowed to contribute to Linux again. We now know what these demands are.

Open Source

The letter, from Mike Dolan, the Linux Foundation’s senior VP and general manager of projects, begins: It has come to our attention that some University of Minnesota (U of MN) researchers appear to have been experimenting on people, specifically the Linux kernel developers, without those developers’ prior knowledge or consent. This was done by proposing known-vulnerable code into the widely-used Linux kernel as part of the work “On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”; other papers and projects may be involved as well. It appears these experiments were performed without prior review or approval by an Institutional Review Board (IRB), which is not acceptable, and an after-the-fact IRB review approved this experimentation on those who did not consent. This is correct. Wu and Lu opened their note to the UMN IRB by stating: “We recently finished a work that studies the patching process of OSS.” They only asked the IRB’s permission after they’d shared the paper’s abstract of the paper on Twitter.  Then after they admitted the abstract’s publication had caused “heated discussion and pushback,” they removed the abstract and apologized to the IRB for causing “many confusions and misunderstandings.”  While the IRB appears to have approved this research after the fact, the Linux kernel community was not kept in the loop. The researchers claim that they spoke to people in the Linux community, but they are never identified. Hence, Kroah-Hartman’s reaction when, once more, he was presented with “nonsense patches” except to think it was yet another attempt to waste the Linux kernel maintainers’ time by “continuing to experiment on the kernel community developers.”

Dolan continued: We encourage and welcome research to improve security and security review processes. The Linux kernel development process takes steps to review code to prevent defects. However, we believe experiments on people without their consent is unethical, and likely involves many legal issues. People are an integral part of the software review and development process. The Linux kernel developers are not test subjects, and must not be treated as such. This is a major point. The researchers first claim in their IRB FAQ that: “This is not considered human research. This project studies some issues with the patching process instead of individual behaviors, and we did not collect any personal information.”  In the next paragraph, though, the UMN researchers back off from this claim.”Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB approval in the beginning. We apologize for the raised concerns. This is an important lesson we learned — Do not trust ourselves on determining human research; always refer to IRB whenever a study might be involving any human subjects in any form.” Dolan went on:  This also wasted their valuable time and put at risk the billions of people around the world who depend on their results. While the U of MN researchers claimed to take steps to prevent inclusion of vulnerabilities in the final software, their failure to gain consent suggests a lack of care. There are also amplified consequences because Linux kernel changes are picked up by many other downstream projects that build off of the kernel codebase. Then we get the heart of the matter. While Dolan said the UMN researchers’ apology was promising, the Linux community needs more. Or, as Kroah-Harman bluntly stated: As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. Until those actions are taken, we do not have anything further to discuss about this issue. These “requests” are: Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments. Finding all this code is a real problem. Senior Linux kernel developer, Al Viro, who spotted the first April bogus patch, noted: “The lack of data is a part of what’s blowing the whole thing out of proportion — if they bothered to attach the list (or link to such) of SHA1 of commits that had come out of their experiment, or, better yet, maintained and provided the list of message-ids of all submissions, successful and not, this mess with blanket revert requests, etc. would’ve been far smaller (if happened at all).” As it is, the Linux developers and committers are now burning time reviewing several hundred UMN Linux kernel patches. They are not amused. Dolan moved on to ask that the paper be withdrawn “from formal publication and formal presentation all research work based on this or similar research where people appear to have been experimented on without their prior consent. Leaving archival information posted on the Internet is fine, as they are mostly already public, but there should be no research credit for such works.”Thanks to the paper’s FAQ, we already know that it has been accepted for publication by the IEEE Symposium on Security and Privacy (IEEE S&P) 2021. This is a top forum for computer security researchers. The 2021 virtual meeting will be happening shortly between May 23 to May 27. The UMN has not said yet whether it will be withdrawn.Dolan pressed to ensure further UMN experiments on people have IRB review prior to the experiment commencing. “Ensure that all future IRB reviews of proposed experiments on people will normally ensure the consent of those being experimented on, per usual research norms and laws,” he said.At this time, the UMN has not responded to our request for information on what the school plans to do. The point of all this, Dolan said, is “to eliminate all potential and perception of damage from these activities, eliminate any perceived benefit from such activities, and prevent their recurrence. We would hope to see productive, appropriate open-source contributions in the future from your students and faculty as we have seen in prior years from your institution.” The Linux Foundation wants the school to respond to these requests as soon as possible. The Linux maintainers also want to know what’s what with the UMN patches, so they can find move on. They would much rather be working on improving Linux than chasing down possible deliberately seeded errors.   So far, they’re not finding any. But when you’re charged with maintaining the most important operating system on the planet, it’s better to be safe than sorry. Related Stories: More

Last week, some University of Minnesota (UMN) security researchers kicked a hornet nest, when it was revealed that they’d tried to insert deliberately buggy patches into Linux. Greg Kroah-Hartman, the well-respected Linux kernel maintainer for the Linux stable branch, responded by banning not only them but any UMN-connected developers from contributing to the Linux kernel. Now, the researchers have sort of, kind of, apologized for their mistakes: “We sincerely apologize for any harm our research group did to the Linux kernel community.” 

Open Source

The apology started well enough. But, Kangjie Lu,  the assistant professor in the Computer Science & Engineering Department of the UMN in charge of the product, and graduate student researchers, Qiushi Wu, and Aditya Pakki continued: Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the “hypocrite commits” paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research and to waste its effort reviewing these patches without its knowledge or permission. You think? This is simply not how Red Team testing is done. At least some of the leaders of the targeted “ethical hacking attack” are made aware that an attack is coming. Otherwise, there’s no real difference between what these researchers did and ordinary, run-of-the-mill criminal hacking.  They continued, “We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities.” They then explained, “The “hypocrite commits” work was carried out in August 2020; it aimed to improve the security of the patching process in Linux. As part of the project, we studied potential issues with the patching process of Linux, including causes of the issues and suggestions for addressing them.”  And, in any case, “This work did not introduce vulnerabilities into the Linux code. The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code. We reported the findings and our conclusions (excluding the incorrect patches) of the work to the Linux community before paper submission, collected their feedback, and included them in the paper. [“On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”]. The researchers continued that: * All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the “hypocrite commits” paper. * These 190 patches were in response to real bugs in the code and all correct–as far as we can discern–when we submitted them. * We understand the desire of the community to gain access to and examine the three incorrect patches. Doing so would reveal the identity of members of the community who responded to these patches on the message board. Therefore, we are working to obtain their consent before revealing these patches.

What is this message board? We don’t know. It appears to not be one of the many official Linux developer mailing lists, nor the main Linux mailing list: The Linux kernel mailing list (LKML). Their apology went awry though in their last point:  * Our recent patches in April 2021 are not part of the “hypocrite commits” paper either. We had been conducting a new project that aims to automatically identify bugs introduced by other patches (not from us). Our patches were prepared and submitted to fix the identified bugs to follow the rules of Responsible Disclosure, and we are happy to share details of this newer project with the Linux community. Kroah-Hartman didn’t see these recent patches as being in the least bit valuable or even trustworthy. As he wrote about those April 2021 patches: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them and published a paper based on that work. Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? When submitting patches created by a tool, everyone who does so submits them with wording like “found by tool XXX, we are not sure if this is correct or not, please advise.” which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect. A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid “fix” is totally negligent on your part, not ours.  You are the one at fault, it is not our job to be the test subjects of a tool you create. Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way. Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose or introduce bugs on purpose.  If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. As for their apology and request to “rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software.” Kroah-Hartman simply stated:  As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. Until those actions are taken, we do not have anything further to discuss about this issue.What are these actions? We don’t know. I’ve asked the appropriate people to comment on the Linux community’s demands. In the meantime, as for the code itself, Kroah-Hartman declared: “Because of this [issue], all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase.” Kees Cook, Google Linux Kernel Engineer and member of The Technical Advisory Board wrote the “Board is taking a look at the history of UMN’s contributions and their associated research projects. At present, it seems the vast majority of patches have been in good faith, but we’re continuing to review the work.” On Twitter, Cook added, “I spent a fair bit of time today going through each of the recent UMN research papers and mapping them to commits. They appear to all be in good faith. There are a small handful of mistakes that got later fixes, but given the volume of commits, that’s expected.” As for UMN, Department of Computer Science and Engineering Mats Heimdahl, Department Head, and Loren Terveen, Associate Department Head, issued a statement in which they stated they’d learned on April 21st, only after Kroah-Hartman brought the matter to the developer world’s attention. They added that they’d learned “about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.”The leaders continued, “We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues if needed. We will report our findings back to the community as soon as practical.”Looking from above, Linux creator Linus Torvalds is reported to have said, “I don’t think it has been a huge deal _technically_, but people are pissed off, and it’s obviously a breach of trust.” Stay tuned. While there appear to be no serious security problems as a result of the UMN blunders, trust lost is not easily regained. And, in the Linux kernel community, where trust is everything, that’s no small matter. Related Stories: More