On 13 December 2016 at 17:03, Daniel Beck <[email protected]> wrote: > Hi everyone, > > We've now had not one, but two unauthenticated remote code execution > vulnerabilities in Jenkins: > > - SECURITY-218 in > https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-11-11 > - SECURITY-360 in > https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-11-16 > > Clearly, the current state of the CLI is a problem. Its Java serialization > based protocol without prior authentication has now repeatedly resulted in > remote code execution. For something like Jenkins, keeper of all the secrets, > this is just unacceptable. > > For now, we have a new system property that allows administrators to disable > all of the CLI. I don't think this is good enough, but it's all we had time > to do for SECURITY-360. > https://jenkins.io/doc/upgrade-guide/2.19/#disabling-the-cli > > So, what are we going to do with the CLI? Remove it altogether? Only allow > access via SSHD? Only allow authenticated use? Don't use remoting? Limit CLI > remoting to specific users? WDYT? > > Daniel
Writing the CLI purely in terms of the REST API would be good - security wise you then have a single path to secure, and no vulns unique to the CLI; obviously some work is entailed :P. -Rob -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJ3HoZ1fkbr4yCPEOk0EbmEygW0ikq0AQrPdKH%3DC8am4Kbcbwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
