{"action":"created","issue":{"url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/7","repository_url":"https://api.github.com/repos/maddingue/Sys-Syslog","labels_url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/7/comments","events_url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/7/events","html_url":"https://github.com/maddingue/Sys-Syslog/pull/7","id":168007161,"number":7,"title":"CVE-2016-1238: avoid loading optional modules from default .","user":{"login":"tonycoz","id":166429,"avatar_url":"https://avatars.githubusercontent.com/u/166429?v=3","gravatar_id":"","url":"https://api.github.com/users/tonycoz","html_url":"https://github.com/tonycoz","followers_url":"https://api.github.com/users/tonycoz/followers","following_url":"https://api.github.com/users/tonycoz/following{/other_user}","gists_url":"https://api.github.com/users/tonycoz/gists{/gist_id}","starred_url":"https://api.github.com/users/tonycoz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tonycoz/subscriptions","organizations_url":"https://api.github.com/users/tonycoz/orgs","repos_url":"https://api.github.com/users/tonycoz/repos","events_url":"https://api.github.com/users/tonycoz/events{/privacy}","received_events_url":"https://api.github.com/users/tonycoz/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2016-07-28T03:35:59Z","updated_at":"2016-08-05T03:07:13Z","closed_at":"2016-08-02T12:53:07Z","pull_request":{"url":"https://api.github.com/repos/maddingue/Sys-Syslog/pulls/7","html_url":"https://github.com/maddingue/Sys-Syslog/pull/7","diff_url":"https://github.com/maddingue/Sys-Syslog/pull/7.diff","patch_url":"https://github.com/maddingue/Sys-Syslog/pull/7.patch"},"body":"Sys::Syslog treats two modules as optional, attemptting to load them\r\nand not requiring them (Win32 only.)\r\n\r\nIf a user runs a program using Sys::Syslog in a world writable\r\ndirectory (like %windir%\\Temp) a local attacker can create\r\nWin32\\EventLog.pm in that directory to run code as the running user.\r\n\r\nThis patch temporarily removes the default . from @INC to prevent\r\nthat attack."},"comment":{"url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/comments/237744362","html_url":"https://github.com/maddingue/Sys-Syslog/pull/7#issuecomment-237744362","issue_url":"https://api.github.com/repos/maddingue/Sys-Syslog/issues/7","id":237744362,"user":{"login":"einhverfr","id":341143,"avatar_url":"https://avatars.githubusercontent.com/u/341143?v=3","gravatar_id":"","url":"https://api.github.com/users/einhverfr","html_url":"https://github.com/einhverfr","followers_url":"https://api.github.com/users/einhverfr/followers","following_url":"https://api.github.com/users/einhverfr/following{/other_user}","gists_url":"https://api.github.com/users/einhverfr/gists{/gist_id}","starred_url":"https://api.github.com/users/einhverfr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/einhverfr/subscriptions","organizations_url":"https://api.github.com/users/einhverfr/orgs","repos_url":"https://api.github.com/users/einhverfr/repos","events_url":"https://api.github.com/users/einhverfr/events{/privacy}","received_events_url":"https://api.github.com/users/einhverfr/received_events","type":"User","site_admin":false},"created_at":"2016-08-05T03:07:12Z","updated_at":"2016-08-05T03:07:12Z","body":"Ok, I just didn't want to get too far off topic with this pull request.  But since this is effectively an invitation, here are some further thoughts.\r\n\r\nHaving a tool that checks directories in @INC at load time would be helpful. Adding a depth of search would allow some control over the startup costs.  Naturally it would have to wrap some things that lib does, but basic directory change operations would have to trigger rechecks of all relative paths as well, and that would impose cost.  This is one reason why I think relative directories are generally a bad practice when specified outside the command line.  The only reason I haven't written a pragma to do this yet is that I would want it to be cross-platform and I am not really sure how to do this on Windows.\r\n\r\nThere is however a blind spot in such a such a tool that would have to be warned about in big red letters.  World writeable cannot be technically specified.  An anonymous ftp dropbox folder is world writeable regardless of file permissions, for example.  So while it adds depth, it doesn't add complete protection by any means.\r\n\r\nSo imagine if we have an anonymous ftp dropbox which contains large numbers of json files.  We want to pretty print them and . is in @INC (for whatever reason -- maybe someone is re-using a shell script that had to specify -I. in another context, or the person who wrote the shell script did not understand the implications of that switch).  Now this tool won't actually help you and someone uploading JSON.pm that injects malicious code at start time would still be quite possible.  Now at some point that's not Perl's problem to solve and one of the big questions is \"what problems in this area *should* Perl solve?  What problems should modules solve? What problems do we hand to scripts?\"\r\n\r\nThe problems here are generic problems, what I call \"garden path\" issues where what is obviously going on and what is actually going on are dangerously different.  But as long as we are programming in high level languages there are going to be such issues.\r\n\r\nPersonally, as a developer, system administrator, and sometimes pen tester, I prefer to have Perl provide a toolset to secure systems.  that sort of toolset needs to be transparent, predictable, and understandable.  One problem with the current approach that is happening (and I think this is dangerous) is that this sort of magical @INC guessing is being pushed as a workaround, but this leads to strange, misleading, and difficult to understand failure cases.  For example, right now on Debian, you have a case where base.pm complains it couldn't find a module and then misreports where it looked and this was pushed out as an urgent security fix with no documentation -- textbook example of \"what not to do\" (breaking behavior changes to standard libraries without documentation or even making sure that error messages are correct).\r\n\r\nThis also means you need to make sure that changes in behavior like this are properly documented, and that they are tested regarding what errors look like so you can provide guidance in your release notes and manual pages.  Yes, this introduces code rot, but the worst thing is, panicked, poorly documented fixes are arguably worse than no fixes at all."}}
{"actor":{"display_login":"einhverfr"}}