Hi all, If you are using Pound / Pen or another load balancer, I believe you should read this: http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel My article refers to Dan Benjamin''s http://hivelogic.com/articles/2006/04/30/preventing_svn_exposure My point is that even though we are preventing Apache from serving anything except a select few file extensions, Mongrel is serving up the files behind the scenes. So, http://myrailsapp.com/.svn/entries exposes Subversion metadata. Go and read the posts, well worth the time: http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel Bye ! -- Fran?ois Beausoleil http://blog.teksol.info/
On Aug 25, 2006, at 8:26 AM, Francois Beausoleil wrote:> Hi all, > > If you are using Pound / Pen or another load balancer, I believe you > should read this: > > http://blog.teksol.info/articles/2006/08/25/subversion-metadata- > exposure-on-mongrel > > My article refers to Dan Benjamin''s > http://hivelogic.com/articles/2006/04/30/preventing_svn_exposure > > My point is that even though we are preventing Apache from serving > anything except a select few file extensions, Mongrel is serving up > the files behind the scenes. > > So, http://myrailsapp.com/.svn/entries exposes Subversion metadata. > > Go and read the posts, well worth the time: > http://blog.teksol.info/articles/2006/08/25/subversion-metadata- > exposure-on-mongrel > > Bye ! > -- > Fran?ois Beausoleil > http://blog.teksol.info/Yup this is a problem with capistrano''s default deploy.rb file. It uses svn co so all the .svn meta data is there by default. I personally always set set :checkout, "export" in my deploy.rb files so this cannot happen just like you mention on your blog. I feel its worth the trade off of not being able to hot patch your current deployment. -Ezra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060825/38691456/attachment.html
On 8/25/06, Francois Beausoleil <francois.beausoleil at gmail.com> wrote:> > Hi all, > > If you are using Pound / Pen or another load balancer, I believe you > should read this: > > > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel > > My article refers to Dan Benjamin''s > http://hivelogic.com/articles/2006/04/30/preventing_svn_exposure > > My point is that even though we are preventing Apache from serving > anything except a select few file extensions, Mongrel is serving up > the files behind the scenes. > > So, http://myrailsapp.com/.svn/entries exposes Subversion metadata. > > Go and read the posts, well worth the time: > > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel > > Bye ! > -- > Fran?ois Beausoleil > http://blog.teksol.info/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-usersYup confirmed it on my application http://localhost:4111/.svn/README.txt shows This is a Subversion working copy administrative directory. Visit http://subversion.tigris.org/ for more information. -daya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20060825/4eb6a808/attachment.html
> If you are using Pound / Pen or another load balancer, I believe you > should read this: > > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel > > My article refers to Dan Benjamin''s > http://hivelogic.com/articles/2006/04/30/preventing_svn_exposure > > My point is that even though we are preventing Apache from serving > anything except a select few file extensions, Mongrel is serving up > the files behind the scenes. > > So, http://myrailsapp.com/.svn/entries exposes Subversion metadata. > > Go and read the posts, well worth the time: > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel >Thanks for pointing that one out! If you do use Pound and don''t want to change your deploy method, just add this to your pound.cfg after ListenHTTP(S): Service URL "\\.svn" end That will give a 503 to anyone trying to access it. This assumes pound is running in front. Note this will block anything with ".svn" in the URL. -John
> This is a Subversion working copy administrative directory. > Visit http://subversion.tigris.org/ for more information.is there actualy anything important in there? i mean if you authenticate with SSH keys, and even if you dont, i dont think it caches passwords? and it surely doesnt cache the entire history ora nything (like a .git dir) so they wont be able to see all the embarassing oneline ''oops, working now'' commits..> > -daya> _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
I don''t see why this is a huge security issue either. At the worst someone can view your commit history by viewing the .svn/entries file. The password auth files are stored in the repository itself, not in the .svn directories in the working copy. Shane Vitarana shanesbrian.net On 8/25/06, carmen <_ at whats-your.name> wrote:> > This is a Subversion working copy administrative directory. > > Visit http://subversion.tigris.org/ for more information. > > is there actualy anything important in there? i mean if you authenticate with SSH keys, and even if you dont, i dont think it caches passwords? and it surely doesnt cache the entire history ora nything (like a .git dir) so they wont be able to see all the embarassing oneline ''oops, working now'' commits.. > > > > > -daya > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >
> I don''t see why this is a huge security issue either. At the worst > someone can view your commit history by viewing the .svn/entries file. > The password auth files are stored in the repository itself, not in > the .svn directories in the working copy.Maybe not huge, but that file gives you logins. Which then helps attack in other ways... and it also let''s them know you''re running subversion and how... so gives them a host to attack perhaps... 2 more cents...> > Shane Vitarana > shanesbrian.net > > On 8/25/06, carmen <_ at whats-your.name> wrote: >>> This is a Subversion working copy administrative directory. >>> Visit http://subversion.tigris.org/ for more information. >> >> is there actualy anything important in there? i mean if you authenticate with SSH keys, and even if you dont, i dont think it caches passwords? and it surely doesnt cache the entire history ora nything (like a .git dir) so they wont be able to see all the embarassing oneline ''oops, working now'' commits.. >> >>> >>> -daya >> >>> _______________________________________________ >>> Mongrel-users mailing list >>> Mongrel-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/mongrel-users >> >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >
On Fri, 2006-08-25 at 11:26 -0400, Francois Beausoleil wrote:> Hi all, > > If you are using Pound / Pen or another load balancer, I believe you > should read this: > > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrel > > My article refers to Dan Benjamin''s > http://hivelogic.com/articles/2006/04/30/preventing_svn_exposure > > My point is that even though we are preventing Apache from serving > anything except a select few file extensions, Mongrel is serving up > the files behind the scenes. > > So, http://myrailsapp.com/.svn/entries exposes Subversion metadata. > > Go and read the posts, well worth the time: > http://blog.teksol.info/articles/2006/08/25/subversion-metadata-exposure-on-mongrelGood points all around, but that''s not really a Mongrel security hole, that''s an svn security hole. The fact that it puts tons of crap into your directories along with all the files it''s managing is always a bad idea. It''s also the reason I use svk and don''t like putting svn online. But, now with everyone using Capistrano I can see this as a pretty big problem. I wonder if you could just modify the cap tasks to simply delete all the .svn directories after the app is deployed? find . -name ".svn" -exec rm -rf {} \; And then problem is permanently solved. I believe this would work with capistrano since it makes whole new checked out directories with svn and doesn''t use it after that. Anyway, good write-up, I''ll add that to the Pound documentation for Mongrel. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Fri, 2006-08-25 at 17:11 +0000, carmen wrote:> > This is a Subversion working copy administrative directory. > > Visit http://subversion.tigris.org/ for more information. > > is there actualy anything important in there? i mean if you authenticate with SSH keys, and even if you dont, i dont think it caches passwords? and it surely doesnt cache the entire history ora nything (like a .git dir) so they wont be able to see all the embarassing oneline ''oops, working now'' commits..You never know what they put in there. Having worked on a RCS before I can tell you all the major authors love tossing the world into their repositories. Passwords, previous revisions that had passwords, your daughter''s baby pictures, all sorts of stuff. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On 26-aug-2006, at 1:07, Zed Shaw wrote:> I wonder if you could just modify the cap tasks to simply > delete all the .svn directories after the app is deployed? > > find . -name ".svn" -exec rm -rf {} \;Wouldn''t this result in the same as doing an export, which Ezra already suggested? -- Regards, Charles.
On Sat, 2006-08-26 at 11:11 +0200, Charles M. Gerungan wrote:> On 26-aug-2006, at 1:07, Zed Shaw wrote: > > > I wonder if you could just modify the cap tasks to simply > > delete all the .svn directories after the app is deployed? > > > > find . -name ".svn" -exec rm -rf {} \; > > Wouldn''t this result in the same as doing an export, which Ezra > already suggested? >Yeps, but doesn''t do it for people who already have their stuff checked out. -- Zed A. Shaw http://www.zedshaw.com/ http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.