Secunia: Some vulnerabilities have been reported in Wesnoth, which can be exploited by malicious people to cause a DoS (Denial of Service), disclose potentially sensitive information, or potentially compromise a vulnerable system. 1) An error within the WML preprocessor can be exploited via a malicious add-on to disclose the content of arbitrary files on an affected system when processing pathnames that contain directory traversal sequences. 2) An error within the handling of the "turn_cmd" option can be exploited to cause a DoS or potentially execute arbitrary commands via a malicious add-on. The vulnerabilities are reported in versions prior to 1.2.8. References: http://www.wesnoth.org/forum/viewtopic.php?p=264289#264289
I forced all archs to stable from 1.2.7 and removed the older vulnerable version.
I inquired upstream to find out a little more about the impact of these vulnerabilities.
Nils Kneuper was kind enough to answer all questions, I'll paste them here. > Secunia [1] describes these as follows: > "1) An error within the WML preprocessor can be exploited via a malicious > add-on to disclose the content of arbitrary files on an affected system > when processing pathnames that contain directory traversal sequences. > > 2) An error within the handling of the "turn_cmd" option can be exploited > to cause a DoS or potentially execute arbitrary commands via a > malicious add-on." > > On your forums, I did not read that (1) would require a malicious add-on, > so my questions are: > > A) Is (1) exploitable only via an add-on? Exactly. You do need some content that is using a syntax which will point to outside the wesnoth dir. Mainline content is not using it, so you need some user made addon. At the time of the release there was no malicious content on our add-on server. > B) How can (1) be triggered? The bug is only exploitable with multiplayer content (basically only with eras) since in all other cases the content of the file would be pasted to stdout but noone else would get it. In a macro there is just a call to a file from outside of the wesnoth dir using ../../../ and so on. > C) Is the possible code execution in (2) only possible via an add-on? We only have about *two* possible commands that can be executed, there is no mainline content doing it, so it has to be some useraddon. At the time of the release there was no malicious content on our add-on server. > D) How can (2) be triggered? I don't know exactly how to trigger it. I just know that it will ends with the endless execution of the system command yes / no. > E) Are any of those add-ons shipped or enabled by default? No, when we talk about add-ons we are talking about usergenerated content. The basic source to get those is via out own add-on server. At the time of the release there was no known content using those exploits. Of course distribution of those addons is possible via any imaginable way (email, some forum attachment, whatever). >>>>> We only have about *two* possible commands that can be executed, >>> Does this relate to in-game commands, like "start game" or "invite >>> player" >>> or to shell commands? Sorry, I don't exactly know how that exploit works. It is somehow triggering the system command 'yes' via some really strange logics ingame resulting in stdout being flooded by 'y's. We were *not* able to exectute any other commands beside yes and no. That is probably everything possible there. There should be no really big problem with it, it is just that the system can be stalled by it and the only way to fix this is to remove the preferences file before starting wesnoth again since this problematic param will be saved in there. In the new version the faulty command was completely removed. I *think* that problem has nothing to do with shell params or whatever. Though I personally did not completely understand how to create the exploit itself but I think it should not be really troublesome for the system. The first exploit is IMO w ahole lot more serious since it allows to read the users files if the location of those is known.
As I understand it, the attack would look like this: I create an add-on (game campaign) and trick a user into playing it, then can DoS himvia (2) and if I play the game together with the victim, I can read arbitrary files via (1). Voting NO on the GLSA side because of low exploitability.
no too, closing.
