Bugzilla – Bug 1073012
[server:mail/tin]: CVE-2017-17520: tin: Command injection in tools/url_handler.pl
Last modified: 2018-01-12 06:07:21 UTC
rh#1526153 ** DISPUTED ** tools/url_handler.pl in TIN 2.4.1 does not validate strings before launching the program specified by the BROWSER environment variable, which might allow remote attackers to conduct argument-injection attacks via a crafted URL. NOTE: a third party has reported that this is intentional behavior, because the documentation states "url_handler.pl was designed to work together with tin which only issues shell escaped absolute URLs." References: https://security-tracker.debian.org/tracker/CVE-2017-17520 References: https://bugzilla.redhat.com/show_bug.cgi?id=1526153 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-17520 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17520
Why is this assigned to me? C.f.: https://build.opensuse.org/package/users/server:mail/tin
you last updated it. but well, you are right. assigned to maintainer
Ahmmm ... never touched nor used tin. Why I've become mainainer of tin? Or is this the default for a project maintainerr to become maitainer of all packages therein? I see jmoellers as well as psmt as maintainers but no bugowner osc cat server:mail tin tin.changes | grep -ic werner 0
(In reply to Marcus Meissner from comment #2) > you last updated it. but well, you are right. assigned to maintainer Yep, I was maintainer then. BTW: while we're at it, the description should be updated not to contact me but the maintainer, if one disagrees with my patches. (ok, I could forward the "demand" for dropping the patch ;) Judging from how long those patches have been in there though and _not one_ has contacted me, I guess nobody disagrees, esp. with the "unread-not-lines.patch" and the default-keybind for rot13 is just taste and what you're used to from e.g. mutt or whatever and easy to override via your own config ;). As that unread-not-lines.patch actually reinstates behaviour that has been in tin since I started using it over 15 years ago and then got replaced by showing "the lines" (which is when I created the initial patch-version)... I should take that up with upstream really, but I'm lazy. And me not being neither maintainer nor bug-owner anymore does not mean I cannot submit updates, eh? Ouh, 2.4.2 was released on 2017-12-24 ;) I think I'll do another update and submit that with that change in description. Someone should then update https://build.opensuse.org/package/meta/server:mail/tin to match. Don't hold your breath though, but a need for patch-rebasing has been rare and easy since I've introduced them. @Werner: yes, inherited from project, AFAIK. Regarding the actual subject of the bug: I've no idea. I guess I could whip up a patch adding URI::Escape or something, but do we want to deviate from upstream? Please contact me via mail on this, as it's a major hassle to login to bugzilla for me ATM (see bsc#1074179). Actually, in all the years I've been using tin, I've never called url_handler.pl ever, AFAIK. So, if it were me, I'd just drop that script (and wait for protest ;) ok, shoulda grep through the source if it's called "hardcoded" somewhere etc. pp., the usual drill... Have a nice and safe new year!
Many happy moments in 2018! As Werner points out in comment 3, I am one of the bugowners of tin, but I got the impression that tin was not distributed any more, so is there actually any need to maintain it?
(In reply to Josef Möllers from comment #5) > Many happy moments in 2018! > > As Werner points out in comment 3, I am one of the bugowners of tin, but I > got the impression that tin was not distributed any more, so is there > actually any need to maintain it? osc se tin | grep ^openSUSE openSUSE:11.4 tin openSUSE:12.1 tin openSUSE:Dropped tin out of order it seems.
Just accepted SR#560735