Re: PGP/GnuPG unsecure, should be replaced?
Hi On 7/21/19 4:34 PM, Malte wrote: li...@miklos.info transcribed 1.4K bytes on 20-Jul-2019 21:25: I checked that article. For e.g. the article says, "If you’re lucky, your local GnuPG defaults to 2048-bit RSA, the 64-bit-block CAST5 cipher in CFB, ..." "defaults to" and "supports" are two different words with two different meanings. GnuPG's history is full of new features getting developed while insecure defaults being kept. Thanks for pointing out. Correct, I was not specific enough. GnuPG *defaults* to AES-128 when using symmetric encryption according to its manual page. In practice, it appears to be using AES-256. I would be surprised if the GnuPG version shipped by the most developer-friendly Linux OS on the planet defaulted to a 64-bit block cipher. Perhaps an earlier version of GnuPG did default to CAST5 block cipher, as Wikipedia article states. qmi
Re: PGP/GnuPG unsecure, should be replaced?
Hi, On 7/19/19 1:34 PM, Stephan Seitz wrote: I found the following article about PGP/GnuPG: https://latacora.singles/2019/07/16/the-pgp-problem.html In short you should drop GnuPG because it doesn’t do anything really the right way. It should be replaced with different tools for different situations. I checked that article. For e.g. the article says, "If you’re lucky, your local GnuPG defaults to 2048-bit RSA, the 64-bit-block CAST5 cipher in CFB, ..." Wrong. The current implementation of GnuPG shipped by Debian Buster - version 2.2.12 - does support modern cryptographic standards for symmetric encryption, not only CAST5. For e.g., it does support twofish and aes. Both of which use 128-bit block sizes, AFAIK. See command output for gpg below about supported algorithms: " qmi@qmiacer:~$ gpg --version gpg (GnuPG) 2.2.12 (...) Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 (...) " So it's good enough, apparently. Debian is using GnuPG for signing files. From the article: Signing Packages Use Signify/Minisign. Ted Unangst will tell you all about it. It’s what You may be right, though. That tool might have better bindings for modern programming languages. Regards, -- qmi Email: li...@miklos.info
Re: "Magellan" bug in sqlite3
On Thu, Dec 20, 2018 at 12:36:23AM +0100, Christoph Moench-Tegeder wrote: > > > > This vulnerability seems to have been already handled. See URL: > > > > https://security-tracker.debian.org/tracker/TEMP-0566326-9A899F > > > > > > No, we should deal with it in stable release, so tracking is important. > > > > > Please check the link above once again. > > Oh well, let's do that, by all means: > - the description reads "sqlite: info leak" - that's not the remote > code execution Tencent has found. In the Tencent link you can read, 1.'Remote code execution, leaking program memory or causing program crashes.' and: 2.'Magellan is a number of vulnerabilities that exist in SQLite.' and: 3.'so this vulnerability has a wide range of influence.' and: 4.'We follow the responsible vulnerability disclosure process and will not disclose the details of the vulnerability in advance... ' The above points 1.2.3.4. might indicate information leakage vulnerability _as well_. > I conclude that "TEMP-0566326-9A899F" is not the vulnerability Tencent > as dubbed "Magellan". Now we do know yes, after further research which you pointed out. My answer was originally, '...seems to have been...'. Not affirmative, but rather guiding. Until there is no clear information on the issue, you cannot conclude it 100% sure what it is exactly about and under which CVE/tracker ID is tracked despite whatever name it is dubbed as. > In fact, PTS at https://tracker.debian.org/pkg/sqlite3 lists "2 security > issues in stretch", one of which is "TEMP-000-AAC0D0" with description > ""Magellan" remote code execution vulnerability". That one lists sqlite3 > version 3.26.0 as vulnerable - which, according to all available sources - > is the fixed version (Tencent: "If your product uses SQLite, please update > to 3.26.0"). I guess this will need fixing? This is correct, it looks it needs fixing in stretch/jessie, it is clearly stated. Not in sid, though, The correct tracker ID is https://security-tracker.debian.org/tracker/TEMP-000-AAC0D0 as you stated, though, I assume that this has been just added very recently. Anyway, the point here is not which exact tracker deals with the issue but to dismiss the false assumption that the reader might have come to, namely, the security issues are not handled - or to be seen not handled - properly in Debian Linux. (... 'CVE is not assigned yet, but we should track and try to fix it.' ... ) Regards, -- qmi | Debian GNU/Linux enthusiast Email: li...@miklos.info WWW: http://www.miklos.info GPG: 3C4B 1364 A379 7366 7FED 260A 2208 F2CE 3FCE A0D3
Re: "Magellan" bug in sqlite3
Hi On Wed, Dec 19, 2018 at 04:40:36PM +0900, Hideki Yamane wrote: > On Tue, 18 Dec 2018 23:36:24 +0100 > qmi wrote: > > This vulnerability seems to have been already handled. See URL: > > https://security-tracker.debian.org/tracker/TEMP-0566326-9A899F > > No, we should deal with it in stable release, so tracking is important. > Please check the link above once again. When a security issue is found and fixed in unstable/sid, it is usually fixed (i.e.: backported) in stable as well. Currently stable Debian release is codenamed 'stretch': " stretch 3.16.2-5+deb9u1 fixed " It is fixed, please update your system. Regards, -- qmi | Debian GNU/Linux enthusiast Email: li...@miklos.info WWW: http://www.miklos.info GPG: 3C4B 1364 A379 7366 7FED 260A 2208 F2CE 3FCE A0D3
Re: "Magellan" bug in sqlite3
Hi This vulnerability seems to have been already handled. See URL: https://security-tracker.debian.org/tracker/TEMP-0566326-9A899F But no CVE assigned as this is not public yet. Additionally, the Tencent team's page itself on the link referred by you state that in order to apply the fix, update to 3.26.0 version. The Debian package in unstable/sid is already at 3.26.0-3. This also indicates that the issue is already handled. https://packages.debian.org/sid/sqlite3 On Mon, Dec 17, 2018 at 02:20:25PM +0900, Hideki Yamane wrote: > Tencent Blade Team released a security advisory about "Magellan" bug > in sqlite, that was fixed in upstream 3.26.0. > See https://blade.tencent.com/magellan/index_en.html > > CVE is not assigned yet, but we should track and try to fix it. > > -- > Hideki Yamane Tell me if I am wrong. Regards, -- qmi | Debian GNU/Linux enthusiast Email: li...@miklos.info WWW: http://www.miklos.info GPG: 3C4B 1364 A379 7366 7FED 260A 2208 F2CE 3FCE A0D3
Re: Questions
Hi On Fri, Nov 16, 2018 at 04:31:39PM +0100, Jérôme Bardot wrote: > Hello i try to harden my debian server. You are welcome to do so. > I want do understand all of this «warning». > If they are false positive maybe this part should be update because > it’s debian related ? On Debian by default the files and directories have 644 or 755 perms unless special cases (i.e. shadow has 640, /root has 740). See the relevant section of the Debian Policy at https://www.debian.org/doc/debian-policy/ch-files.html#permissions-and-owners. By default the Debian OS is not hardened. However, your mileage may vary, so you are welcome to harden your Debian OS if you are concerned about security or you simply would like to apply a more stringent security policy. In addition to making sure you apply the latest security updates from security.debian.org in your APT settings (i.e. /etc/apt/sources.list), you can harden the your OS by using one or the combination of the following methods: 1- Set up HIDS (OSSEC) 2- Install file/directory integrity checker (i.e. Tripwire) 3- Run remote vulnerability scans (i.e. Openvas, Nessus) See https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html#s-intrusion-detect . Regards, -- qmi | Debian GNU/Linux enthusiast WWW: www.miklos.info GPG: 3C4B 1364 A379 7366 7FED 260A 2208 F2CE 3FCE A0D3
