On Tuesday, 29 April 2014, Mani Azizzadeh <mani.azizza...@gmail.com> wrote:
> > Hey Stephen, > > > Thank you for your answer, just some follow up questions. This setting > that you are talking about, is it something that is turned on by default? > What is the setting called? > I can't recall exactly. Basically the master side if the channel can flag the slave side as untrusted. > So if an attacker should get access to a slave, then he/she cannot just > execute some arbitrary code or command on the master, right? > Well... Assuming you turn on that setting... First the attacker needs to get around code signing. Depending on the launch strategy this may not be that big an issue. Next the attacker needs to get an exported object reference. If you don't have one of them then all you are doing is executing code on the slave side and the master is safe. Once the attacker has an exported object reference then they need that reference to provide a method that takes a String and parses it as Groovy or JavaScript and doesn't go through the sandbox. I know of no such exported object reference, but with 1k plugins there *could* be one. Once they get that, they are home and dry... The code they execute on the master can pull over whatever they want. If the channel says both sides are trusted then the attacker just has to get a ref to the channel to execute remote code.... Remoting will gladly push over their classes for them. Maven job type uses remoting between slave and maven as well as between slave and master, so that allows a compromised build to *theoretically* hop all the way to the master. Maybe 5-10 people could do such a trickery at present and none of those that I know would want to. > And if using a freestyle project then the attacker will not even be able > to inject any custom code to be run on the master? > Never say never > > Sorry for all the questions... :) > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to > jenkinsci-users+unsubscr...@googlegroups.com<javascript:_e(%7B%7D,'cvml','jenkinsci-users%2bunsubscr...@googlegroups.com');> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
