Ubuntu has issued an advisory on November 12: https://usn.ubuntu.com/3815-1/ Mageia 6 is also affected.
Whiteboard: (none) => MGA6TOO
Suggested advisory: ======================== The updated packages fix a security vulnerability: An issue was discovered in GNU gettext 0.19.8. There is a double free in default_add_message in read-catalog.c, related to an invalid free in po_gram_parse in po-gram-gen.y, as demonstrated by lt-msgfmt. (CVE-2018-18751) References: https://usn.ubuntu.com/3815-1/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18751 ======================== Updated packages in core/updates_testing: ======================== gettext-0.19.8.1-1.1.mga6 lib(64)intl8-0.19.8.1-1.1.mga6 lib(64)gettextmisc-0.19.8.1-1.1.mga6 gettext-devel-0.19.8.1-1.1.mga6 gettext-base-0.19.8.1-1.1.mga6 from SRPMS: gettext-0.19.8.1-1.1.mga6.src.rpm
CVE: (none) => CVE-2018-18751Status: NEW => ASSIGNEDWhiteboard: MGA6TOO => (none)Assignee: bugsquad => qa-bugsSource RPM: gettext-0.19.8.1-3.mga7.src.rpm => gettext-0.19.8.1-1.mga6.src.rpmCC: (none) => nicolas.salgueroVersion: Cauldron => 6
Mageia 6, x86_64 CVE-2018-18751 https://github.com/CCCCCrash/POCs/blob/master/Bin/Tools-gettext-0.19.8.1/doublefree/poc $ msgfmt --check poc1 poc1:17: duplicate message definition... poc1:16: ...this is the location of the first definition poc1:18:3: syntax error poc1:18: keyword "n" unknown poc1:19: end-of-line within string poc1:28: duplicate message definition... poc1:24: ...this is the location of the first definition *** Error in `msgfmt': double free or corruption (fasttop): 0x0000000000c7e4b0 *** [...] Aborted (core dumped) https://github.com/CCCCCrash/POCs/blob/master/Bin/Tools-gettext-0.19.8.1/heapcorruption/poc $ msgfmt --check poc2 poc2:9: end-of-line within string poc2: warning: Charset missing in header. Message conversion to user's charset will not work. poc2:20: duplicate message definition... poc2:11: ...this is the location of the first definition poc2:38: end-of-file within string poc2:32: duplicate message definition... poc2:11: ...this is the location of the first definition Segmentation fault (core dumped) Updated the packages. Ran the PoCs again. $ msgfmt --check poc1 poc1:17: duplicate message definition... poc1:16: ...this is the location of the first definition poc1:18:3: syntax error [...] poc1:50:397: invalid control sequence poc1:51: end-of-line within string msgfmt: too many errors, aborting Aborted cleanly, no core dump. $ msgfmt --check poc2 poc2:9: end-of-line within string poc2: warning: Charset missing in header. Message conversion to user's charset will not work. poc2:20: duplicate message definition... poc2:11: ...this is the location of the first definition poc2:38: end-of-file within string poc2:32: duplicate message definition... poc2:11: ...this is the location of the first definition msgfmt: found 4 fatal errors Good also - no segfault. There is a quick tutorial for gettext at http://www.labri.fr/perso/fleury/posts/programming/a-quick-gettext-tutorial.html Shall have a look at that later.
CC: (none) => tarazed25
The tutorial indicated in comment 2 enables the user to set up the project directory structure and write a helloworld program in C and generate the pot, po and mo files. The user supplies the translations - she should ignore the information messages which come up. e.g. "A translation team for your language (fr) does not exist yet." A makefile is supplied but it is informative to work through the example line by line. The project structure looks like this after running the commands: $ tree hello ├── hello ├── hello.c └── po ├── fr │ ├── hello.mo │ ├── hello.po │ └── LC_MESSAGES │ └── hello.mo └── hello.pot Ran the compile command: $ gcc -I. -Wall -Wextra -std=c99 -g -o hello hello.c $ ./hello $ ./hello Hello World So, it does not work! All the intermediate stages work fine so there must be something wrong with the invocation or else the tutorial is just plain wrong about the placing of the .mo file.
Sorry. I messed up the cut and paste. $ ./hello Hello World $ LANG=fr_FR ./hello Hello World So, it does not work!
The hello.mo file is binary but some text can be seen including the strings: Language: fr MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=(n > 1); and Bonjour le monde
Finally: $ echo $LC_MESSAGES en_GB.UTF-8 $ LC_MESSAGES=fr_FR.UTF-8 bash: warning: setlocale: LC_MESSAGES: cannot change locale (fr_FR.UTF-8)
Keywords: (none) => feedback
(In reply to Len Lawrence from comment #6) > Finally: > $ echo $LC_MESSAGES > en_GB.UTF-8 > $ LC_MESSAGES=fr_FR.UTF-8 > bash: warning: setlocale: LC_MESSAGES: cannot change locale (fr_FR.UTF-8) It seems the problem is that you do not French locale in your system. Is the issue still present if you install the package named locales-fr?
Thanks for the suggestion Nicolas. locales-fr now installed. Tried again but hello failed to output French. Recompiled just in case but no change. $ LC_MESSAGES=fr_FR.UTF-8 $ LANG=fr_FR ./hello Hello World This is the program: #include <stdio.h> #include <stdlib.h> #include <libintl.h> #include <locale.h> #define _(STRING) gettext(STRING) int main() { /* Setting the i18n environment */ setlocale (LC_ALL, ""); bindtextdomain ("hello", getenv("PWD")); textdomain ("hello"); /* Example of i18n usage */ printf(_("Hello World\n")); return EXIT_SUCCESS; } This is the tail end of the po/fr/hello.po file: #. Example of i18n usage : hello.c:17 , c-format msgid "Hello World\n" msgstr "Bonjour le monde\n" Originally there those first three lines were all comments.
Further to comment #8, I added a print statement after the helloworld message to see what value the script found for the LANG variable and it returns fr_FR when invoked with "LANG=fr_FR ./hello". Also, I had forgotten to rebuild hello.mo after one of my edits. It is now in po/fr/LC_MESSAGES but the result is the same. Is that the correct place for the mo file?
This is the hello.po file now: # French translations for Hello package. # Copyright (C) 2018 THE Hello'S COPYRIGHT HOLDER # This file is distributed under the same license as the Hello package. # Len Lawrence <tarazed25@gmail.com>, 2018. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Hello 1.0\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2018-11-18 10:05+0000\n" "PO-Revision-Date: 2018-11-18 10:15+0000\n" "Last-Translator: Len Lawrence <tarazed25@gmail.com>\n" "Language-Team: French\n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n" #. Example of i18n usage #: hello.c:17 #, c-format msgid "Hello World\n" msgstr "Bonjour le monde\n"
Here is the tree that worked for me: hello ├── fr │ └── LC_MESSAGES │ └── hello.mo ├── hello ├── hello.c └── po ├── fr │ └── hello.po └── hello.pot
This looked hopeful. My tree structure now looks exactly like yours Nicolas but I still cannot get the string to translate. There must be something else that I have overlooked.
My environment looks like this: LANG=fr_FR.UTF-8 LANGUAGE=fr_FR.UTF-8:fr LC_PAPER=fr_FR.UTF-8 LC_ADDRESS=fr_FR.UTF-8 LC_MONETARY=fr_FR.UTF-8 LC_SOURCED=1 LC_NUMERIC=fr_FR.UTF-8 LC_TELEPHONE=fr_FR.UTF-8 LC_MESSAGES=fr_FR.UTF-8 LC_COLLATE=fr_FR.UTF-8 LC_IDENTIFICATION=fr_FR.UTF-8 LC_MEASUREMENT=fr_FR.UTF-8 LC_CTYPE=fr_FR.UTF-8 LC_TIME=fr_FR.UTF-8 LC_NAME=fr_FR.UTF-8 Maybe you have to set LC_CTYPE=fr_FR.UTF-8 to make it work.
OK, shall follow that up later because it would be important to know for future tests. Whatever the outcome, the package is vindicated by your own tests and the successful PoCs. Thanks.
Done that. The one which seems to make the difference is $ LANGUAGE=fr_FR.UTF-8:fr $ LANG=fr_FR.UTF-8 ./hello Bonjour le monde fr_FR.UTF-8 Good for 64-bits.
Whiteboard: (none) => MGA6-64-OK
Keywords: feedback => (none)
Advisory from comment 1. What a lot of work for you, Len! Validating.
Keywords: (none) => advisory, validated_updateCC: (none) => lewyssmith, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0464.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED