search

eddelbuettel / bh

R package providing Boost Header files
85 stars 33 forks source link

travis: verify travis-tool.sh before executing #38

Closed williamcroberts closed 7 years ago

williamcroberts commented 7 years ago

Currently, grabbing the travis-tool.sh via http could be subject to http man-in-the-middle attacks.

Switch to grabbing travis-tool.sh via https and verify the file with sha256 before execution.

Signed-off-by: William Roberts william.c.roberts@intel.com

williamcroberts commented 7 years ago

This could also be done by just doing a git clone of that repo...

eddelbuettel commented 7 years ago

Not bad. Please ignore travis-tool.sh -- I maintain a 'fork' of that older (generation one) Travis set here and generally switch my repos to its run.sh. Basic functionality is similar so I guess I could fold your PR in and then change.

Then again, we are taking about a man-in-the-middle on system "we" cannot access, ie Travis.

eddelbuettel commented 7 years ago

But I liked the idea and will switch to that. Trouble is ... once I update run.sh (happens once in a while) ALL clients break. Not sure I like that. Any other approaches you could think of?

williamcroberts commented 7 years ago

If it was me, i'd just git clone my tool repo, I can switch this PR to that method.

williamcroberts commented 7 years ago

Since I don't know exactly how you got all this set up, ill abandon, and I'll let you make that simple change.

eddelbuettel commented 7 years ago

There are two git clones here. One is that repo for which we run continuous integration. Travis clone this.

I am doing the http pull here to get a script running the test. Yes, that could be man-in-the-middle'd but it produces nothing but Travis pass or fail so not sure just how serious the attack vector is.

If you want to see a repo with the newer script see for example this widely used one. Thanks for any and all feedback.

williamcroberts commented 7 years ago

Well outside of lying to you, this could be an entry point for attacks into the travis build infrastructure. Think, I could get travis to run some exploit code, break out of the container and put a root kit in it, now I have a potential slave node in a bot net. Unlikely yes, but possible. At least when folks commit, their will be an audit trail of registered user X submitting patch Y that was doing nefarious things. These CI systems can pose a headache to the farms maintaining them....

eddelbuettel commented 7 years ago

Not belittling this but that is ... basically the business risk the CI provider, here Travis. We are already curtailed (max 10 min without i/o, max 60 min job) so it is not that this is likely to be used to create a botnet.

Also, while I have you here: If I just changed from http

curl -OLs http://eddelbuettel.github.io/r-travis/run.sh && chmod 0755 run.sh

to https

curl -OLs https://eddelbuettel.github.io/r-travis/run.sh && chmod 0755 run.sh

I'd be golden too, no?

williamcroberts commented 7 years ago

Yes it is the risk of the CI provider. I initially did that, I don't know why I abandoned it, looking at it again, it should be fine.

williamcroberts commented 7 years ago

Also, just because your account has limited builds, it only takes one execution of something like dirty cow to bypass a lot of this. Again, it depends on how the CI system is set up to deal with threats, it's all on them, I just wouldn't want to be the project that is the entry point.