CVE-2021-4122 Has a Reserved status (at time of comment) so there doesn't appear to be any information available. Where are you getting your info about the vulnerability?
Regarding the LUKS CVE, "The decryption step is performed after a valid user activates the device with a correct passphrase and modified metadata." So it seems that the disk must already be unlocked in order to exploit the CVE.
Naw... They need physical access to overwite the device header with one containing these specific commands, and then when the user enters their passphase to mount the volume it tricks LUKS into disabling encryption on the device, making it decypher the drive into plaintext. The attacker would then have to gain access to the drive a second time to read the now decyphered plaintext data. It's sort of an evil maid attack. One which is unfortunately easy to pull off, provided that the user keeps the volume mounted long enough for the decryption to occur. It's quite probable that if the drive is dismounted durring the decryption process (which is fairly likely) it will corrupt the filesystem, rendering it difficult to read. This is something I would often see when working for a certain OS (who I won't name). Users would contact us because they couldn't boot into our OS, and we would determine that the volume was corrupted because they shut the computer down while it was in the middle of disabling FDE. Or, sometimes they would do this when there wasn't enough memory, or free disk space to write the data. In any case, something caused the process to fail to finish properly. There were almost always remedies for recovery. Sometimes, it required several days of working with the client, and several undisclosed hacks. But, I'm an expert, and I live by the moto there is always a way to save the data (provided it hasn't been overwritten). I saved a few corporations from total meltdown this way, and after everyone else said to "just format the disk, it's a lost cause". Not on my watch. If they were willing to spend the time, and do as I said, I could help them recover eveything, even the still encrypted portion. This probably isn't something an evil maid could pull off, however. It's very time intensive, and would be overtly obvious that something unusual was going on.
This reminds me of an article called "who pays to fix open souce bugs" (or something like that), which made a really good point: lots of corporations do use open source software, one way or another. It would be a really good idea for those corporations to contribute to the projects that they use, so that more programmers can search for and fix vulnerabilities, instead of just relying on software that was made by altruistic people on their own free time. Most of the Internet runs on open source, after all! If open source received all of the attention and investment it deserves, vulnerabilities would be detected much earlier, and even feature enhancements would be much more frequent.
The wonderful world of IT and IOT. As a retired seasoned sys/net/app tech and dev, any app that required elevated access was sent back to be reworked so that elevated access was not required. It was a protracted argument then, and these days I'm sure it's no different.
![ผัวเถื่อน - ยูริ โตเกียวมิวสิค [ OFFICIAL MUSIC VIDEO ]](http://i.ytimg.com/vi/P08ORRVDGl8/mqdefault.jpg)
Begs a question, how many vulnerabilities are still there that lie dormant, waiting to be exploited?
CVE-2021-4122 Has a Reserved status (at time of comment) so there doesn't appear to be any information available. Where are you getting your info about the vulnerability?
Regarding the LUKS CVE, "The decryption step is performed after a valid user activates the device with a correct passphrase and modified metadata." So it seems that the disk must already be unlocked in order to exploit the CVE.
Always a priceless learning experience, even for a seasoned tech
29:29 Can we start call it Log4J pandemic now? ;)
I wonder if the LUKS vulnerability can be used to swap the password on the encrypted disk, giving the admin a nasty surprise at the next reboot
Naw... They need physical access to overwite the device header with one containing these specific commands, and then when the user enters their passphase to mount the volume it tricks LUKS into disabling encryption on the device, making it decypher the drive into plaintext. The attacker would then have to gain access to the drive a second time to read the now decyphered plaintext data. It's sort of an evil maid attack. One which is unfortunately easy to pull off, provided that the user keeps the volume mounted long enough for the decryption to occur. It's quite probable that if the drive is dismounted durring the decryption process (which is fairly likely) it will corrupt the filesystem, rendering it difficult to read. This is something I would often see when working for a certain OS (who I won't name). Users would contact us because they couldn't boot into our OS, and we would determine that the volume was corrupted because they shut the computer down while it was in the middle of disabling FDE. Or, sometimes they would do this when there wasn't enough memory, or free disk space to write the data. In any case, something caused the process to fail to finish properly. There were almost always remedies for recovery. Sometimes, it required several days of working with the client, and several undisclosed hacks. But, I'm an expert, and I live by the moto there is always a way to save the data (provided it hasn't been overwritten). I saved a few corporations from total meltdown this way, and after everyone else said to "just format the disk, it's a lost cause". Not on my watch. If they were willing to spend the time, and do as I said, I could help them recover eveything, even the still encrypted portion. This probably isn't something an evil maid could pull off, however. It's very time intensive, and would be overtly obvious that something unusual was going on.
This reminds me of an article called "who pays to fix open souce bugs" (or something like that), which made a really good point: lots of corporations do use open source software, one way or another. It would be a really good idea for those corporations to contribute to the projects that they use, so that more programmers can search for and fix vulnerabilities, instead of just relying on software that was made by altruistic people on their own free time. Most of the Internet runs on open source, after all! If open source received all of the attention and investment it deserves, vulnerabilities would be detected much earlier, and even feature enhancements would be much more frequent.
The wonderful world of IT and IOT. As a retired seasoned sys/net/app tech and dev, any app that required elevated access was sent back to be reworked so that elevated access was not required. It was a protracted argument then, and these days I'm sure it's no different.
Yeah, maybe call this the "Security Digest" to not confuse it with other general thematic episodes?
So how do I patch this problem on my local linux system?
Without watch liked it seems trust on content