Re: Security risk of vim swap files
2017-11-07 15:46 GMT+03:00 Bram Moolenaar: > > Nikolay Pavlov wrote: > >> 2017-11-06 23:33 GMT+03:00 Bram Moolenaar : >> > >> > Scott Court wrote: >> > >> >> Those are very valid points, and I agree that the way Neovim handles >> >> .swp files is better. I've already explained on here and on Openwall >> >> numerous reasons why I believe that is the best solution and made the >> >> case that .swp files should be stored in ~/.vim/swap by default. However >> >> Bram has veto power and shot that idea down. >> >> >> >> So instead I'm trying to find the next best way to address this. >> >> /var/lib being writable only by root and therefore requiring cooperation >> >> from packagers did not occur to me, but that's definitely a problem. >> >> Maybe it would be doable as a major change in the next major release of >> >> Vim, but you're right; that definitely won't work as a security patch. >> >> So much for that idea. >> >> >> >> I maintain a Linux Distribution (Cucumber Linux) and have already >> >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just >> >> have to hope that other distributions independently start doing >> >> something similar, as Bram seems pretty convinced this problem is >> >> completely a user error and has nothing to do with the way Vim works; >> >> he's also pretty set on not changing the default .swp location. >> > >> > There are a few situations you need to consider: >> > - Removable media, editing a file on a USB stick. >> > - Remote file systems (where the mount point may change over time). >> > - Multiple users editing a shared file. >> > - Renaming directories. >> > >> > There are likely many more >> >> - Remote file systems is a case *against* using swap files in the >> current directory, should they be slow Vim starts being unresponsive >> when it does something with swap file. > > I don't get this. I use remote file systems all the time, from > different systems. Having the swap file in the same directory has saved > my work quite a number of times. Sudden disconnects are the main thing, > having to go to the file from a different system and use "vim -r". That > is impossible if the swap file is on a system that became unreachable. > If the original file becomes unreachable you can't do anything anyway. > > On top of that, having the warning that a swap file exists, meaning you > already changed the file from another system, also often is a life > saver. Happens for me quite often when working on a test that fails on > MS-Windows. > >> - Removable media is a case against swap files as well: while nowadays >> you are unlikely to exhaust write cycles or cause unresponsiveness by >> using swap files there, there are still considerations like >> >> 1. Whether “user saved and removed the media without properly >> closing the editor or wiping out buffer” is less common scenario then >> “user removed the media without …, but did not save and now wants to >> restore on another machine”. Swap files there are welcome only if >> second scenario is more common, but there is a second point as well. > > That's exactly what happens: you edit a file on a USB stick, do > something else, have to catch a train, close the laptop without saving, > take the stick elsewhere, and now your swap file is on a system at home > while you are at work... > >> 2. Removable media is also commonly used for sharing not between >> computers belonging to one user, but between computers belonging to >> different users. Swap files would be nothing other then annoying >> garbage when shared with a user not using *Vim and either using >> Windows (i.e. OS which does not hide dotfiles) or having his file >> manager configured to show hidden files. Also if files with swap files >> nearby were edited on such a machine trying to restore something from >> them will do more harm then good. > > That does not match my experience, sounds uncommon to me. > >> - Swap files are utterly useless for preventing editing a single file >> by multiple users: way too many conditions need to be true for that to >> work: users need to both use *Vim, users need to both have configured >> to save swap files in the current directory, users need to pay >> attention and not discard the message thinking e.g. that it was an >> artifact from previous disconnect. > > It works very well for me. In multi-user setups it does get more > tricky, but using your personal store for swap files isn't going to be > an improvement in any way. > > The only situation I'm aware of is when the swap file gets picked up by > a tool in an unwanted way. E.g. when creating an archive from a > directory or a version control system that isn't setup to ignore swap > files. In that case you want to set 'directory', that's what it is for. How would it help in deleting swap files? Simple test: ``` % mkdir abc % touch abc/{a,b,c} % vim -u NONE -i NONE -N --cmd 'set hidden' abc/? -c 'bufdo normal! i' -c 'set
Re: Security risk of vim swap files
Nikolay Pavlov wrote: > 2017-11-06 23:33 GMT+03:00 Bram Moolenaar: > > > > Scott Court wrote: > > > >> Those are very valid points, and I agree that the way Neovim handles > >> .swp files is better. I've already explained on here and on Openwall > >> numerous reasons why I believe that is the best solution and made the > >> case that .swp files should be stored in ~/.vim/swap by default. However > >> Bram has veto power and shot that idea down. > >> > >> So instead I'm trying to find the next best way to address this. > >> /var/lib being writable only by root and therefore requiring cooperation > >> from packagers did not occur to me, but that's definitely a problem. > >> Maybe it would be doable as a major change in the next major release of > >> Vim, but you're right; that definitely won't work as a security patch. > >> So much for that idea. > >> > >> I maintain a Linux Distribution (Cucumber Linux) and have already > >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just > >> have to hope that other distributions independently start doing > >> something similar, as Bram seems pretty convinced this problem is > >> completely a user error and has nothing to do with the way Vim works; > >> he's also pretty set on not changing the default .swp location. > > > > There are a few situations you need to consider: > > - Removable media, editing a file on a USB stick. > > - Remote file systems (where the mount point may change over time). > > - Multiple users editing a shared file. > > - Renaming directories. > > > > There are likely many more > > - Remote file systems is a case *against* using swap files in the > current directory, should they be slow Vim starts being unresponsive > when it does something with swap file. I don't get this. I use remote file systems all the time, from different systems. Having the swap file in the same directory has saved my work quite a number of times. Sudden disconnects are the main thing, having to go to the file from a different system and use "vim -r". That is impossible if the swap file is on a system that became unreachable. If the original file becomes unreachable you can't do anything anyway. On top of that, having the warning that a swap file exists, meaning you already changed the file from another system, also often is a life saver. Happens for me quite often when working on a test that fails on MS-Windows. > - Removable media is a case against swap files as well: while nowadays > you are unlikely to exhaust write cycles or cause unresponsiveness by > using swap files there, there are still considerations like > > 1. Whether “user saved and removed the media without properly > closing the editor or wiping out buffer” is less common scenario then > “user removed the media without …, but did not save and now wants to > restore on another machine”. Swap files there are welcome only if > second scenario is more common, but there is a second point as well. That's exactly what happens: you edit a file on a USB stick, do something else, have to catch a train, close the laptop without saving, take the stick elsewhere, and now your swap file is on a system at home while you are at work... > 2. Removable media is also commonly used for sharing not between > computers belonging to one user, but between computers belonging to > different users. Swap files would be nothing other then annoying > garbage when shared with a user not using *Vim and either using > Windows (i.e. OS which does not hide dotfiles) or having his file > manager configured to show hidden files. Also if files with swap files > nearby were edited on such a machine trying to restore something from > them will do more harm then good. That does not match my experience, sounds uncommon to me. > - Swap files are utterly useless for preventing editing a single file > by multiple users: way too many conditions need to be true for that to > work: users need to both use *Vim, users need to both have configured > to save swap files in the current directory, users need to pay > attention and not discard the message thinking e.g. that it was an > artifact from previous disconnect. It works very well for me. In multi-user setups it does get more tricky, but using your personal store for swap files isn't going to be an improvement in any way. The only situation I'm aware of is when the swap file gets picked up by a tool in an unwanted way. E.g. when creating an archive from a directory or a version control system that isn't setup to ignore swap files. In that case you want to set 'directory', that's what it is for. > Also Vim does not provide any way to do anything sensible with the > situation “two users simultaneously edit the same file”. False > positives and negatives do not make the situation better as well: > neither Vim checks whether currently running process with PID stored > in swap file has anything to do with the creator of swap files, nor >
Re: Security risk of vim swap files
On Di, 07 Nov 2017, Nikolay Aleksandrovich Pavlov wrote: > - Yet another case *against* the idea of `set directory=.`: consider > the simple script which simulates renaming directory without closing > the file: It is not about renaming a directory while simultaneously editing a file. What is meant with renaming a directory is, that if you have a swapfile from a crashed session laying around (and the path has changed because of moving/renaming a path component in between), Vim will automatically notice that a previous editing session crashed and offer you a way to recover your file. Christian -- Sein Jahrhundert kann man nicht verändern, aber man kann sich dagegenstellen und glückliche Wirkungen vorbereiten. -- Johann Wolfgang von Goethe (Lehrjahre) -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
2017-11-07 1:27 GMT+03:00 Christoffer Aasted: > I’d like to add that few programs litter the filesystem like this. It is > much more common for multi-user systems via ssh to get disconnected and > leave a swap. It would make more sense to recreate a temporary directory for > this. I’m not so much in for the security, but I believe in retaining the > ability to trigger a warning on editing the same file on multi-user - > meanwhile avoiding using the whole filesystem and network shares for this > unless explicitly enabled. There could be multiple solutions for this and I > believe Bram would have a say that could improve this refactoring if it > could be done. Well, you got a warning and now what? Warning itself is useless without a plan for handling the issue. Could you at least first write an exact plan how *you* are going to handle the situation in your specific case? Then imagine that you want to extend `:h E325` with a more useful and multi-user-environment-adapted advice then just “you must find out what the situation is yourself”. I guess that would include, at least, `ps` and somehow determining the machine identifier (e.g. IP or internal hostname) of whoever connected to a ssh (because in some cases different people may not have dedicated users and instead connect using a single one); then somehow connecting `ps` output (likely user name) or machine identifier with some kind of communication channel. And lots of if’s covering permission issues. One should also not forget that advice will probably start with “open another shell” or “copy the information and press Q”: user may want to retain data displayed with E325 to e.g. start checking the process ID, but Vim is rather unfriendly here, this data is not even in `:messages` and `` does not work. Also you should not forget one thing: if you have E325 then some other user *may* be editing the same file you are editing. But both it is *may*, and the opposite is absolutely not true: there are lots of cases when other user is editing the same file as you, but you do not get a warning because he - is not using Vim; - prefers to use scp://; - has different setting; - … This means that unless you have an agreement with all your collegues to use Vim in a set way the mechanizm is absolutely unreliable and thus better be not used for the purpose to not make you have a feeling of the false safety. On the other hand if you *do* have an agreement you *don’t* need to rely on Vim defaults: just also agree e.g. that some value will be set in /etc/vimrc and must not be overridden by vimrc, it is also not impossible to create autocommands which will check following that agreement automatically. > > On Mon, 6 Nov 2017 at 22.26, Nikolay Aleksandrovich Pavlov > wrote: >> >> 2017-11-06 23:33 GMT+03:00 Bram Moolenaar : >> > >> > Scott Court wrote: >> > >> >> Those are very valid points, and I agree that the way Neovim handles >> >> .swp files is better. I've already explained on here and on Openwall >> >> numerous reasons why I believe that is the best solution and made the >> >> case that .swp files should be stored in ~/.vim/swap by default. >> >> However >> >> Bram has veto power and shot that idea down. >> >> >> >> So instead I'm trying to find the next best way to address this. >> >> /var/lib being writable only by root and therefore requiring >> >> cooperation >> >> from packagers did not occur to me, but that's definitely a problem. >> >> Maybe it would be doable as a major change in the next major release of >> >> Vim, but you're right; that definitely won't work as a security patch. >> >> So much for that idea. >> >> >> >> I maintain a Linux Distribution (Cucumber Linux) and have already >> >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll >> >> just >> >> have to hope that other distributions independently start doing >> >> something similar, as Bram seems pretty convinced this problem is >> >> completely a user error and has nothing to do with the way Vim works; >> >> he's also pretty set on not changing the default .swp location. >> > >> > There are a few situations you need to consider: >> > - Removable media, editing a file on a USB stick. >> > - Remote file systems (where the mount point may change over time). >> > - Multiple users editing a shared file. >> > - Renaming directories. >> > >> > There are likely many more >> >> - Remote file systems is a case *against* using swap files in the >> current directory, should they be slow Vim starts being unresponsive >> when it does something with swap file. >> - Removable media is a case against swap files as well: while nowadays >> you are unlikely to exhaust write cycles or cause unresponsiveness by >> using swap files there, there are still considerations like >> >> 1. Whether “user saved and removed the media without properly >> closing the editor or wiping out buffer” is less common scenario then >> “user removed the
Re: Security risk of vim swap files
I’d like to add that few programs litter the filesystem like this. It is much more common for multi-user systems via ssh to get disconnected and leave a swap. It would make more sense to recreate a temporary directory for this. I’m not so much in for the security, but I believe in retaining the ability to trigger a warning on editing the same file on multi-user - meanwhile avoiding using the whole filesystem and network shares for this unless explicitly enabled. There could be multiple solutions for this and I believe Bram would have a say that could improve this refactoring if it could be done. On Mon, 6 Nov 2017 at 22.26, Nikolay Aleksandrovich Pavlov < zyx@gmail.com> wrote: > 2017-11-06 23:33 GMT+03:00 Bram Moolenaar: > > > > Scott Court wrote: > > > >> Those are very valid points, and I agree that the way Neovim handles > >> .swp files is better. I've already explained on here and on Openwall > >> numerous reasons why I believe that is the best solution and made the > >> case that .swp files should be stored in ~/.vim/swap by default. However > >> Bram has veto power and shot that idea down. > >> > >> So instead I'm trying to find the next best way to address this. > >> /var/lib being writable only by root and therefore requiring cooperation > >> from packagers did not occur to me, but that's definitely a problem. > >> Maybe it would be doable as a major change in the next major release of > >> Vim, but you're right; that definitely won't work as a security patch. > >> So much for that idea. > >> > >> I maintain a Linux Distribution (Cucumber Linux) and have already > >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just > >> have to hope that other distributions independently start doing > >> something similar, as Bram seems pretty convinced this problem is > >> completely a user error and has nothing to do with the way Vim works; > >> he's also pretty set on not changing the default .swp location. > > > > There are a few situations you need to consider: > > - Removable media, editing a file on a USB stick. > > - Remote file systems (where the mount point may change over time). > > - Multiple users editing a shared file. > > - Renaming directories. > > > > There are likely many more > > - Remote file systems is a case *against* using swap files in the > current directory, should they be slow Vim starts being unresponsive > when it does something with swap file. > - Removable media is a case against swap files as well: while nowadays > you are unlikely to exhaust write cycles or cause unresponsiveness by > using swap files there, there are still considerations like > > 1. Whether “user saved and removed the media without properly > closing the editor or wiping out buffer” is less common scenario then > “user removed the media without …, but did not save and now wants to > restore on another machine”. Swap files there are welcome only if > second scenario is more common, but there is a second point as well. > 2. Removable media is also commonly used for sharing not between > computers belonging to one user, but between computers belonging to > different users. Swap files would be nothing other then annoying > garbage when shared with a user not using *Vim and either using > Windows (i.e. OS which does not hide dotfiles) or having his file > manager configured to show hidden files. Also if files with swap files > nearby were edited on such a machine trying to restore something from > them will do more harm then good. > > - Swap files are utterly useless for preventing editing a single file > by multiple users: way too many conditions need to be true for that to > work: users need to both use *Vim, users need to both have configured > to save swap files in the current directory, users need to pay > attention and not discard the message thinking e.g. that it was an > artifact from previous disconnect. > > Also Vim does not provide any way to do anything sensible with the > situation “two users simultaneously edit the same file”. False > positives and negatives do not make the situation better as well: > neither Vim checks whether currently running process with PID stored > in swap file has anything to do with the creator of swap files, nor > there is any way to determine whether simultaneous editing actually > happens in “remote file system with access from different machines” > and “access from same machine, but separated via various means like > PID namespaces” cases. Enough false alarms and users will stop caring > about them. > > - Yet another case *against* the idea of `set directory=.`: consider > the simple script which simulates renaming directory without closing > the file: > > mkdir test-br.d > #vim -u NONE -i NONE -N \ > #test-br.d/file \ > #-c write -c '!mv test-br.d test-ar.d' \ > #-c 'file test-ar.d/file' \ > vim -u NONE -i NONE -N \ > test-br.d/file \ > -c write \ >
Re: Security risk of vim swap files
2017-11-06 23:33 GMT+03:00 Bram Moolenaar: > > Scott Court wrote: > >> Those are very valid points, and I agree that the way Neovim handles >> .swp files is better. I've already explained on here and on Openwall >> numerous reasons why I believe that is the best solution and made the >> case that .swp files should be stored in ~/.vim/swap by default. However >> Bram has veto power and shot that idea down. >> >> So instead I'm trying to find the next best way to address this. >> /var/lib being writable only by root and therefore requiring cooperation >> from packagers did not occur to me, but that's definitely a problem. >> Maybe it would be doable as a major change in the next major release of >> Vim, but you're right; that definitely won't work as a security patch. >> So much for that idea. >> >> I maintain a Linux Distribution (Cucumber Linux) and have already >> adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just >> have to hope that other distributions independently start doing >> something similar, as Bram seems pretty convinced this problem is >> completely a user error and has nothing to do with the way Vim works; >> he's also pretty set on not changing the default .swp location. > > There are a few situations you need to consider: > - Removable media, editing a file on a USB stick. > - Remote file systems (where the mount point may change over time). > - Multiple users editing a shared file. > - Renaming directories. > > There are likely many more - Remote file systems is a case *against* using swap files in the current directory, should they be slow Vim starts being unresponsive when it does something with swap file. - Removable media is a case against swap files as well: while nowadays you are unlikely to exhaust write cycles or cause unresponsiveness by using swap files there, there are still considerations like 1. Whether “user saved and removed the media without properly closing the editor or wiping out buffer” is less common scenario then “user removed the media without …, but did not save and now wants to restore on another machine”. Swap files there are welcome only if second scenario is more common, but there is a second point as well. 2. Removable media is also commonly used for sharing not between computers belonging to one user, but between computers belonging to different users. Swap files would be nothing other then annoying garbage when shared with a user not using *Vim and either using Windows (i.e. OS which does not hide dotfiles) or having his file manager configured to show hidden files. Also if files with swap files nearby were edited on such a machine trying to restore something from them will do more harm then good. - Swap files are utterly useless for preventing editing a single file by multiple users: way too many conditions need to be true for that to work: users need to both use *Vim, users need to both have configured to save swap files in the current directory, users need to pay attention and not discard the message thinking e.g. that it was an artifact from previous disconnect. Also Vim does not provide any way to do anything sensible with the situation “two users simultaneously edit the same file”. False positives and negatives do not make the situation better as well: neither Vim checks whether currently running process with PID stored in swap file has anything to do with the creator of swap files, nor there is any way to determine whether simultaneous editing actually happens in “remote file system with access from different machines” and “access from same machine, but separated via various means like PID namespaces” cases. Enough false alarms and users will stop caring about them. - Yet another case *against* the idea of `set directory=.`: consider the simple script which simulates renaming directory without closing the file: mkdir test-br.d #vim -u NONE -i NONE -N \ #test-br.d/file \ #-c write -c '!mv test-br.d test-ar.d' \ #-c 'file test-ar.d/file' \ vim -u NONE -i NONE -N \ test-br.d/file \ -c write \ -c '!mv test-br.d test-ar.d' \ -c 'bw' \ -c 'edit test-ar.d/file' What will you see in both commented and uncommented cases? Right, E325: ATTENTION! Is there any value in seeing it? No, file was already saved, PID belongs to the same Vim instance, but, unfortunately, you can’t delete that swap file from Vim menu for Vim process being “already running”. But should you have rm -rf test-br?.d mkdir test-br.d mkdir test-swap.d vim -u NONE -i NONE -N \ --cmd 'let =getcwd()."/test-swap.d//"' \ test-br.d/file \ -c write \ -c '!mv test-br.d test-ar.d' \ -c 'bw' \ -c 'edit test-ar.d/file' and Vim automatically and correctly deletes the no-longer-needed swap file attached to the previous location of the file. > > -- > FATAL ERROR!
Re: Security risk of vim swap files
2017-11-06 23:14 GMT+03:00 Gary Johnson: > On 2017-11-06, Scott Court wrote: >> Those are very valid points, and I agree that the way Neovim handles >> .swp files is better. I've already explained on here and on Openwall >> numerous reasons why I believe that is the best solution and made the >> case that .swp files should be stored in ~/.vim/swap by default. However >> Bram has veto power and shot that idea down. >> >> So instead I'm trying to find the next best way to address this. >> /var/lib being writable only by root and therefore requiring cooperation >> from packagers did not occur to me, but that's definitely a problem. >> Maybe it would be doable as a major change in the next major release of >> Vim, but you're right; that definitely won't work as a security patch. >> So much for that idea. > > What about using /var/tmp instead of /var/lib? It's writable by > everyone and my notes say that it is not cleared at power-up, but my > notes don't include a reference for that claim. It is rather distribution-specific. AFAIR I have seen distributions where this is the same as /tmp (one or the other is a symlink), missing or not actually writeable by not root. Third is my case BTW, though I do not remember whether it is Gentoo default or I have messed up something; in any case no apps complain about such state of things: I only have three directories there and all are related to system package manager: 1. /var/tmp/portage with user:group portage:portage, 0775. The default location for build files. 2. /var/tmp/distfiles, root:portage, 0775. Not default location, but my own preference for where to keep source code archives. 3. /var/tmp/genkernel, root:root, 0755. Default location for genkernel temporary files used when it builds the kernel. `man hier` states that /var/tmp is like /tmp, but for “temporary files stored for an unspecified duration” and that it itself is from FHS version 2.3, so probably I messed up something with permissions (handbook also briefly mentions 1777 permissions for /var/tmp), but still it works like that. > > Regards, > Gary > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to vim_dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Scott Court wrote: > Those are very valid points, and I agree that the way Neovim handles > .swp files is better. I've already explained on here and on Openwall > numerous reasons why I believe that is the best solution and made the > case that .swp files should be stored in ~/.vim/swap by default. However > Bram has veto power and shot that idea down. > > So instead I'm trying to find the next best way to address this. > /var/lib being writable only by root and therefore requiring cooperation > from packagers did not occur to me, but that's definitely a problem. > Maybe it would be doable as a major change in the next major release of > Vim, but you're right; that definitely won't work as a security patch. > So much for that idea. > > I maintain a Linux Distribution (Cucumber Linux) and have already > adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just > have to hope that other distributions independently start doing > something similar, as Bram seems pretty convinced this problem is > completely a user error and has nothing to do with the way Vim works; > he's also pretty set on not changing the default .swp location. There are a few situations you need to consider: - Removable media, editing a file on a USB stick. - Remote file systems (where the mount point may change over time). - Multiple users editing a shared file. - Renaming directories. There are likely many more -- FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On 2017-11-06, Scott Court wrote: > Those are very valid points, and I agree that the way Neovim handles > .swp files is better. I've already explained on here and on Openwall > numerous reasons why I believe that is the best solution and made the > case that .swp files should be stored in ~/.vim/swap by default. However > Bram has veto power and shot that idea down. > > So instead I'm trying to find the next best way to address this. > /var/lib being writable only by root and therefore requiring cooperation > from packagers did not occur to me, but that's definitely a problem. > Maybe it would be doable as a major change in the next major release of > Vim, but you're right; that definitely won't work as a security patch. > So much for that idea. What about using /var/tmp instead of /var/lib? It's writable by everyone and my notes say that it is not cleared at power-up, but my notes don't include a reference for that claim. Regards, Gary -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Those are very valid points, and I agree that the way Neovim handles .swp files is better. I've already explained on here and on Openwall numerous reasons why I believe that is the best solution and made the case that .swp files should be stored in ~/.vim/swap by default. However Bram has veto power and shot that idea down. So instead I'm trying to find the next best way to address this. /var/lib being writable only by root and therefore requiring cooperation from packagers did not occur to me, but that's definitely a problem. Maybe it would be doable as a major change in the next major release of Vim, but you're right; that definitely won't work as a security patch. So much for that idea. I maintain a Linux Distribution (Cucumber Linux) and have already adopted the Neovim style ~/.vim/swap approach on there. Maybe we'll just have to hope that other distributions independently start doing something similar, as Bram seems pretty convinced this problem is completely a user error and has nothing to do with the way Vim works; he's also pretty set on not changing the default .swp location. On 11/06/2017 01:20 PM, Nikolay Aleksandrovich Pavlov wrote: > 2017-11-06 20:39 GMT+03:00 Scott Court: >> Update: I just read through the Filesystem Hierarchy Standard more >> carefully, and it appears there actually is a directory for this purpose: >> /var/lib in which the FHS states we can create a /var/lib/vim/swap >> subdirectory in for this purpose. >> >> From >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBLTEDITORGTEDITORBACKUPFILESAN >> >> /var/lib/ : Editor backup files and state (optional) >> >> Purpose >> >> These directories contain saved files generated by any unexpected >> termination of an editor (e.g., elvis, jove, nvi). >> >> Other editors may not require a directory for crash-recovery files, but may >> require a well-defined place to store other information while the editor is >> running. This information should be stored in a subdirectory under /var/lib >> (for example, GNU Emacs would place lock files in /var/lib/emacs/lock). >> >> Maybe we should store the .swp files there. > That needs active support from package maintainers: on my system > (Gentoo) /var/lib is writeable only by root and I do not think that is > uncommon. So Vim cannot create a directory there on its own when run > by a user and it needs to be created by a package when it is > installed. And there is still a question regarding what to do on > Windows. > > Neovim has currently chosen to store swap, undo, backup (fallback, > first directory is still dot) and view files under $XDG_DATA_HOME/nvim > (Windows: $XDG_DATA_HOME is %LOCALAPPDATA%, but suffix is `nvim-data` > unlike just `nvim` on *nix because $XDG_CONFIG_HOME is also > %LOCALAPPDATA% (our choice and not a standard, XDG does not apply on > Windows)). Reasoning (including “why you should not consider > ‘preventing simultaneous access’ a valid argument for existence of > swap files in a particular location”) may be seen in > https://github.com/neovim/neovim/issues/4481. > >> >> >> On 11/06/2017 12:29 PM, Scott Court wrote: >> >> The problem with storing the .swp tiles in /tmp though is that (on most >> distributions) /tmp gets cleared on every reboot, which is a problem >> since one of the major purposes of .swp files is to allow recovery of a >> vim session after system crash/hard reboot. >> >> Also, the default Apache httpd config does permit serving of . (dot) files. >> >> Perhaps we should store the swap files in a sticky directory visible by >> all users that is a) not ever going to be on a **shared** NFS and b) not >> going to be cleared on reboot (say /var/cache/vim/swap), and then set >> the permissions for all .swp files to 0600. >> >> It's also not really reasonable to expect every user of Vim to be aware >> of every potential security vulnerability and edit his configuration >> files to protect against them. See the first paragraph of the "Secure by >> Default" section at https://www.openbsd.org/security.html. >> >> >> On 11/06/2017 11:29 AM, dezz...@gmail.com wrote: >> >> On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: >> >> It is true, that this can cause a problem. However, I am not sure its >> correct to blame vim here. >> >> First, I think you need to configure your webserver to be able to view >> dotfiles. I believe a default installation of at least apache won't let >> you show dotfiles. Second, I wonder why those swapfiles are not deleted. >> Somehow Vim must have crashed or be killed and in that case one >> certainly don't want that the swapfiles are deleted (think of recovery). >> >> I agree. Although a multi-user system usually is connected via ssh - in that >> same scenario sometimes the connection is interrupted or people are on flaky >> wifi. This leaves ~ swapfiles littered over the system more frequently as a >> multi-user system over ssh. Which gives more reason to not litter the >> current directory
Re: Security risk of vim swap files
Update: I just read through the Filesystem Hierarchy Standard more carefully, and it appears there actually is a directory for this purpose: /var/lib in which the FHS states we can create a /var/lib/vim/swap subdirectory in for this purpose. From http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBLTEDITORGTEDITORBACKUPFILESAN > > /var/lib/ : Editor backup files and state (optional) > > > Purpose > > These directories contain saved files generated by any unexpected > termination of an editor (e.g., *elvis*, *jove*, *nvi*). > > Other editors may not require a directory for crash-recovery files, > but may require a well-defined place to store other information while > the editor is running. This information should be stored in a > subdirectory under /var/lib (for example, GNU Emacs would place lock > files in /var/lib/emacs/lock). > Maybe we should store the .swp files there. On 11/06/2017 12:29 PM, Scott Court wrote: > The problem with storing the .swp tiles in /tmp though is that (on most > distributions) /tmp gets cleared on every reboot, which is a problem > since one of the major purposes of .swp files is to allow recovery of a > vim session after system crash/hard reboot. > > Also, the default Apache httpd config does permit serving of . (dot) files. > > Perhaps we should store the swap files in a sticky directory visible by > all users that is a) not ever going to be on a **shared** NFS and b) not > going to be cleared on reboot (say /var/cache/vim/swap), and then set > the permissions for all .swp files to 0600. > > It's also not really reasonable to expect every user of Vim to be aware > of every potential security vulnerability and edit his configuration > files to protect against them. See the first paragraph of the "Secure by > Default" section at https://www.openbsd.org/security.html. > > > On 11/06/2017 11:29 AM, dezz...@gmail.com wrote: >> On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: >>> It is true, that this can cause a problem. However, I am not sure its >>> correct to blame vim here. >>> First, I think you need to configure your webserver to be able to view >>> dotfiles. I believe a default installation of at least apache won't let >>> you show dotfiles. Second, I wonder why those swapfiles are not deleted. >>> Somehow Vim must have crashed or be killed and in that case one >>> certainly don't want that the swapfiles are deleted (think of recovery). >> I agree. Although a multi-user system usually is connected via ssh - in that >> same scenario sometimes the connection is interrupted or people are on flaky >> wifi. This leaves ~ swapfiles littered over the system more frequently as a >> multi-user system over ssh. Which gives more reason to not litter the >> current directory for multi-user environments even with the argument of >> people editing the same file. Most people are annoyed by littered files over >> a filesystem. >> >>> One could argue, that swap files should be stored below ~/.vim directory >>> tree. But what if several users edit the same file? One also needs to >>> make sure, the path would be encoded into the name, but then we might >>> run into trouble with filename length limitations. >> A shared directory in /tmp for all vim instances on a multi-user system >> would solve the issue while not littering the filesystem. >> >>> So I think it in the users responsibility to configure Vim correctly >>> (check the directory option) to not have him litter his document root >>> with old swap files. >> Almost every .vimrc I've ever read had a line to set directory to exclude >> current directory and it is more an annoyance than a feature when countless >> people are asking this question over and over again what filename~ files >> are. I agree vim should be geared towards multi-user systems as well and >> warn when appropriate. It just makes more sense to have it in $TMP in that >> case and retain that behaviour. >> > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Security risk of vim swap files
The problem with storing the .swp tiles in /tmp though is that (on most distributions) /tmp gets cleared on every reboot, which is a problem since one of the major purposes of .swp files is to allow recovery of a vim session after system crash/hard reboot. Also, the default Apache httpd config does permit serving of . (dot) files. Perhaps we should store the swap files in a sticky directory visible by all users that is a) not ever going to be on a **shared** NFS and b) not going to be cleared on reboot (say /var/cache/vim/swap), and then set the permissions for all .swp files to 0600. It's also not really reasonable to expect every user of Vim to be aware of every potential security vulnerability and edit his configuration files to protect against them. See the first paragraph of the "Secure by Default" section at https://www.openbsd.org/security.html. On 11/06/2017 11:29 AM, dezz...@gmail.com wrote: > On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: >> It is true, that this can cause a problem. However, I am not sure its >> correct to blame vim here. > >> First, I think you need to configure your webserver to be able to view >> dotfiles. I believe a default installation of at least apache won't let >> you show dotfiles. Second, I wonder why those swapfiles are not deleted. >> Somehow Vim must have crashed or be killed and in that case one >> certainly don't want that the swapfiles are deleted (think of recovery). > I agree. Although a multi-user system usually is connected via ssh - in that > same scenario sometimes the connection is interrupted or people are on flaky > wifi. This leaves ~ swapfiles littered over the system more frequently as a > multi-user system over ssh. Which gives more reason to not litter the current > directory for multi-user environments even with the argument of people > editing the same file. Most people are annoyed by littered files over a > filesystem. > >> One could argue, that swap files should be stored below ~/.vim directory >> tree. But what if several users edit the same file? One also needs to >> make sure, the path would be encoded into the name, but then we might >> run into trouble with filename length limitations. > A shared directory in /tmp for all vim instances on a multi-user system would > solve the issue while not littering the filesystem. > >> So I think it in the users responsibility to configure Vim correctly >> (check the directory option) to not have him litter his document root >> with old swap files. > Almost every .vimrc I've ever read had a line to set directory to exclude > current directory and it is more an annoyance than a feature when countless > people are asking this question over and over again what filename~ files are. > I agree vim should be geared towards multi-user systems as well and warn when > appropriate. It just makes more sense to have it in $TMP in that case and > retain that behaviour. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Security risk of vim swap files
On Tuesday, October 31, 2017 at 3:11:55 PM UTC+1, Christian Brabandt wrote: > It is true, that this can cause a problem. However, I am not sure its > correct to blame vim here. > First, I think you need to configure your webserver to be able to view > dotfiles. I believe a default installation of at least apache won't let > you show dotfiles. Second, I wonder why those swapfiles are not deleted. > Somehow Vim must have crashed or be killed and in that case one > certainly don't want that the swapfiles are deleted (think of recovery). I agree. Although a multi-user system usually is connected via ssh - in that same scenario sometimes the connection is interrupted or people are on flaky wifi. This leaves ~ swapfiles littered over the system more frequently as a multi-user system over ssh. Which gives more reason to not litter the current directory for multi-user environments even with the argument of people editing the same file. Most people are annoyed by littered files over a filesystem. > One could argue, that swap files should be stored below ~/.vim directory > tree. But what if several users edit the same file? One also needs to > make sure, the path would be encoded into the name, but then we might > run into trouble with filename length limitations. A shared directory in /tmp for all vim instances on a multi-user system would solve the issue while not littering the filesystem. > So I think it in the users responsibility to configure Vim correctly > (check the directory option) to not have him litter his document root > with old swap files. Almost every .vimrc I've ever read had a line to set directory to exclude current directory and it is more an annoyance than a feature when countless people are asking this question over and over again what filename~ files are. I agree vim should be geared towards multi-user systems as well and warn when appropriate. It just makes more sense to have it in $TMP in that case and retain that behaviour. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Zdenek Dohnal[171103 09:27]: > On 11/03/2017 02:07 PM, Marvin Renich wrote: > > * zdoh...@redhat.com [171103 03:45]: > Can other users open original file, which has .swp file belonging to > certain user:group with permissions 0600, as read-only with your > solution? If not, it could be change of behavior, which can make some > people unhappy -> that' why I thought it could be configurable behavior. Yes. My current version (from Debian package; see below) will give the "recovery" prompt, and then allow the user to edit it anyway (based on the answer to the prompt). This looks like it is working just right. VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 13 2017 22:38:50) Included patches: 1-1144 ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Someone wrote: > Another option would be to copy the user and other permissions from the > original file, but reset the group permissions to 0. For example, if a > user goes to edit a file with permissions 754, the .swp file would have > the permissions 704. This prevents the security problem with .swp files > while still allowing anyone to recover changes for files that were world > readable to begin with. This might be a good compromise. To cover the case that the user has his configuration wrong and has a primary group that gives too many users access, we can attempt to change the group of the swap file to that of the original file. If that works then we can keep using the same permissions. If that fails, the group is now different, we can set the group bits to zero. We can OR them with the world bits (some systems have the weird behavior that when the group matches it ignores the world bits, restricting permission if you happen to be in the lucky group). > Still I think the least problematic solution though is to use a separate > directory for the .swp files. Also, what happens if a user goes to edit > a file that he has write access to in a directory that he doesn't have > write access to? Where does the .swp file get placed then? With the > approach separate directory approach this becomes a nonissue. Read the docs, it's covered. -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~ /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On 11/03/2017 02:07 PM, Marvin Renich wrote: > * zdoh...@redhat.com[171103 03:45]: >>> Another solution would be to always use the editing user's user:group >>> and perm 0600. >> I agree with this solution. And IMO the best way would be to create >> option for configure script+create option for vimrc configuration >> file, which can turn on/off this behavior (IMHO it's good to have >> option for users, who doesn't want this behavior). > I think having this behavior configurable is overkill and unnecessary in > practice. Can other users open original file, which has .swp file belonging to certain user:group with permissions 0600, as read-only with your solution? If not, it could be change of behavior, which can make some people unhappy -> that' why I thought it could be configurable behavior. -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Security risk of vim swap files
Another option would be to copy the user and other permissions from the original file, but reset the group permissions to 0. For example, if a user goes to edit a file with permissions 754, the .swp file would have the permissions 704. This prevents the security problem with .swp files while still allowing anyone to recover changes for files that were world readable to begin with. This might be a good compromise. Still I think the least problematic solution though is to use a separate directory for the .swp files. Also, what happens if a user goes to edit a file that he has write access to in a directory that he doesn't have write access to? Where does the .swp file get placed then? With the approach separate directory approach this becomes a nonissue. On 11/03/2017 09:07 AM, Marvin Renich wrote: > * zdoh...@redhat.com[171103 03:45]: >>> Another solution would be to always use the editing user's user:group >>> and perm 0600. >> I agree with this solution. And IMO the best way would be to create >> option for configure script+create option for vimrc configuration >> file, which can turn on/off this behavior (IMHO it's good to have >> option for users, who doesn't want this behavior). > I think having this behavior configurable is overkill and unnecessary in > practice. > > After thinking about it, I like my second solution (the one above) best. > My first solution has the advantage that anyone who has permission to > edit the file will be able to recover a crashed editing session. But I > don't see this as a real-world scenario. The above solution is simpler > to implement, simpler to understand, and makes it easier to identify > security implications. > > I also think my first solution might cause problems if the containing > directory has the restricted deletion flag permission bit. > > ...Marvin > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: Security risk of vim swap files
* zdoh...@redhat.com[171103 03:45]: > > Another solution would be to always use the editing user's user:group > > and perm 0600. > > I agree with this solution. And IMO the best way would be to create > option for configure script+create option for vimrc configuration > file, which can turn on/off this behavior (IMHO it's good to have > option for users, who doesn't want this behavior). I think having this behavior configurable is overkill and unnecessary in practice. After thinking about it, I like my second solution (the one above) best. My first solution has the advantage that anyone who has permission to edit the file will be able to recover a crashed editing session. But I don't see this as a real-world scenario. The above solution is simpler to implement, simpler to understand, and makes it easier to identify security implications. I also think my first solution might cause problems if the containing directory has the restricted deletion flag permission bit. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Friday, November 3, 2017 at 8:44:51 AM UTC+1, zdo...@redhat.com wrote: > > Another solution would be to always use the editing user's user:group > > and perm 0600. > > I agree with this solution. And IMO the best way would be to create option > for configure script+create option for vimrc configuration file, which can If that's possible. > turn on/off this behavior (IMHO it's good to have option for users, who > doesn't want this behavior). > > Zdenek -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
> Another solution would be to always use the editing user's user:group > and perm 0600. I agree with this solution. And IMO the best way would be to create option for configure script+create option for vimrc configuration file, which can turn on/off this behavior (IMHO it's good to have option for users, who doesn't want this behavior). Zdenek -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Christian Brabandt[171102 16:50]: > > On Do, 02 Nov 2017, z...@z5t1.com wrote: > > > > > However, there is another problem with the swap file permissions > > that has not yet been discussed: when Vim creates swap files, the > > .swp file is created with the owner and group set to the user who is > > editing the file (hereafter referred to as the "editor") and the > > editor's primary group respectively. The permission bits on the swap > > file are the same as the original file. > > > > This is a problem, as the editor's primary group may be different > > from the group of the file being edited. Take /etc/shadow for > > example. That file is supposed to have the permissions 640 with > > owner: root, group: shadow as a quick `ls -l` shows: > > > > -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow > > > > However, shadow is not the root user's primary group; on this system > > it happens to be 'users', which every other user on the system is > > also a member of. Now if root goes to edit the file, a swap file is > > created in /etc/.shadow.swp with the following permissions: > > > > -rw-r- 1 root users 4096 Nov 2 13:52 /etc/.shadow.swp > > > > This swap file is now readable by every user on the system. Keep in > > mind the /etc/shadow file contains hashes of every user's password, > > so now the password for every single user on the system may have > > been compromised. > > That looks like a problem. I agree. One solution is if the user doing the editing has permission to create the swap file with the original file's user:group, then do that with the original file's perms. Otherwise use the editing user's user:group and perm 0600. Another solution would be to always use the editing user's user:group and perm 0600. There might need to be more logic added to recover to check if the current user has rw permission on the swap file. However, this might very well just 'work' (i.e. fail gracefully) with the current code. Re Bram's question about root's default group being users: While that seems like a bad idea in general, the situation could still come up with very reasonable user/group combinations. Take a 'normal' user whose default group is users, but who also happens to be a member of group staff. A file with root:staff ownership and 0660 perms would have a swap file with someone:users and perms 0660, thus giving most users rw access to the swap file when they had neither r nor w access to the original. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Thank you Christian; I'm tweaking my configuration as you suggested. On 11/02/17 16:50, Christian Brabandt wrote: > > What is with files that are edited by several users possibly at the same > time? They won't get a warning message now. I thought about this. As I said, my fix has some issues. One possible solution I thought of was modifying vim to create a .filename.lock file in the directory of the file you are editing, but with nothing in it. Vim can the check for the existence of a .lock file to determine if the file is locked for editing, and further check the owner of that file to determine who has locked the file for editing. This still allows for vim to prevent multiple users from inadvertently editing the same file at once without risking disclosing the file contents to unintended parties. If I get a chance, I will try to write a patch doing this. On 11/02/17 16:50, Christian Brabandt wrote: > On Do, 02 Nov 2017, z...@z5t1.com wrote: > >> However, there is another problem with the swap file permissions that has >> not yet been discussed: when Vim creates swap files, the .swp file is >> created with the owner and group set to the user who is editing the file >> (hereafter referred to as the "editor") and the editor's primary group >> respectively. The permission bits on the swap file are the same as the >> original file. >> >> This is a problem, as the editor's primary group may be different from the >> group of the file being edited. Take /etc/shadow for example. That file is >> supposed to have the permissions 640 with owner: root, group: shadow as a >> quick `ls -l` shows: >> >> -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow >> >> However, shadow is not the root user's primary group; on this system it >> happens to be 'users', which every other user on the system is also a member >> of. Now if root goes to edit the file, a swap file is created in >> /etc/.shadow.swp with the following permissions: >> >> -rw-r- 1 root users 4096 Nov 2 13:52 /etc/.shadow.swp >> >> This swap file is now readable by every user on the system. Keep in mind the >> /etc/shadow file contains hashes of every user's password, so now the >> password for every single user on the system may have been compromised. > That looks like a problem. > >> --- Solution --- >> >> I have found this problem can be mitigated by changing the swap directory >> with the 'set directory' directive as Hanno originally suggested. I have >> added the following lines to my '/etc/vimrc': >> >> " Move the swap file location to protect against CVE-2017-1000382 >> silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null > you likely want to add a check if the directory exists, so that not > every time Vim is called, it needs to shell out. Note, there is also > `system()` available. See `:h isdirectory()` and `:h system()` > >> set directory=~/.vim/swap/ > ,[ :h 'directory' ]- > | - For Unix and Win32, if a directory ends in two path separators "//" > | or "\\", the swap file name will be built from the complete path to > | the file with all path separators substituted to percent '%' signs. > | This will ensure file name uniqueness in the preserve directory. > ` > >> This safely sets the swap file directory to a directory that should >> not cause any security problems. For added security, the directory is >> created so that only the owner has access to it, regardless of how the >> system's umask or .swp file permissions are set. > What is with files that are edited by several users possibly at the same > time? They won't get a warning message now. > >> Additionally, the swap file collision (if you edit both ~/foo/file and >> ~/bar/file at the same time) is not a major issue; Vim detects this >> and gives the second swap file a different file extension. When you go >> to restore from the swap file, you get a prompt asking which swap file >> you want to use (if there are two swap files with the same basename), >> which doesn't strike me as being terribly problematic. While this >> approach may have some minor issues/quirks, for me it seems far >> preferable to being vulnerable to this vulnerability. > And how do you know from which swap file to recover? Additionally, if > there is ~/.vim/swap/.foo.txt.swp and ~/.vim/swap/.foo.txt.swo and the > first swap file is removed (after the editing session finishes), you > won't get a swap file recovery message anymore when editing a file for > which only ~/.vim/swap/.foo.txt.swo exists. > >> I have already applied this fix on Cucumber Linux and thought you may >> want to consider applying a similar fix upstream. > You might want to tweak your setting as mentioned above. > > Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups
Re: Security risk of vim swap files
z5t1 (???) wrote: > Hi, I'd like to add my two cents to this. > > I have reproduced this on Centos 6 and Cucumber Linux 1.0. We have > established that the umask plays no role in the permissions on swap files; > Vim creates its swap files with the same permissions as the file being edited. > > However, there is another problem with the swap file permissions that has not > yet been discussed: when Vim creates swap files, the .swp file is created > with the owner and group set to the user who is editing the file (hereafter > referred to as the "editor") and the editor's primary group respectively. The > permission bits on the swap file are the same as the original file. > > This is a problem, as the editor's primary group may be different from the > group of the file being edited. Take /etc/shadow for example. That file is > supposed to have the permissions 640 with owner: root, group: shadow as a > quick `ls -l` shows: > > -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow > > However, shadow is not the root user's primary group; on this system it > happens to be 'users', which every other user on the system is also a member > of. Now if root goes to edit the file, a swap file is created in > /etc/.shadow.swp with the following permissions: > > -rw-r- 1 root users 4096 Nov 2 13:52 /etc/.shadow.swp > > This swap file is now readable by every user on the system. Keep in mind the > /etc/shadow file contains hashes of every user's password, so now the > password for every single user on the system may have been compromised. Eh, why is root's primary group one that all users on the system are a member of? That is asking for trouble. Every file that root creates will be readable by everybody by default. > --- Solution --- > > I have found this problem can be mitigated by changing the swap directory > with the 'set directory' directive as Hanno originally suggested. I have > added the following lines to my '/etc/vimrc': > > " Move the swap file location to protect against CVE-2017-1000382 > silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null > set directory=~/.vim/swap/ > > This safely sets the swap file directory to a directory that should not cause > any security problems. For added security, the directory is created so that > only the owner has access to it, regardless of how the system's umask or .swp > file permissions are set. > > Additionally, the swap file collision (if you edit both ~/foo/file and > ~/bar/file at the same time) is not a major issue; Vim detects this and gives > the second swap file a different file extension. When you go to restore from > the swap file, you get a prompt asking which swap file you want to use (if > there are two swap files with the same basename), which doesn't strike me as > being terribly problematic. While this approach may have some minor > issues/quirks, for me it seems far preferable to being vulnerable to this > vulnerability. > > I have already applied this fix on Cucumber Linux and thought you may want to > consider applying a similar fix upstream. -- Kisses may last for as much as, but no more than, five minutes. [real standing law in Iowa, United States of America] /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Do, 02 Nov 2017, z...@z5t1.com wrote: > > However, there is another problem with the swap file permissions that has not > yet been discussed: when Vim creates swap files, the .swp file is created > with the owner and group set to the user who is editing the file (hereafter > referred to as the "editor") and the editor's primary group respectively. The > permission bits on the swap file are the same as the original file. > > This is a problem, as the editor's primary group may be different from the > group of the file being edited. Take /etc/shadow for example. That file is > supposed to have the permissions 640 with owner: root, group: shadow as a > quick `ls -l` shows: > > -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow > > However, shadow is not the root user's primary group; on this system it > happens to be 'users', which every other user on the system is also a member > of. Now if root goes to edit the file, a swap file is created in > /etc/.shadow.swp with the following permissions: > > -rw-r- 1 root users 4096 Nov 2 13:52 /etc/.shadow.swp > > This swap file is now readable by every user on the system. Keep in mind the > /etc/shadow file contains hashes of every user's password, so now the > password for every single user on the system may have been compromised. That looks like a problem. > > --- Solution --- > > I have found this problem can be mitigated by changing the swap directory > with the 'set directory' directive as Hanno originally suggested. I have > added the following lines to my '/etc/vimrc': > > " Move the swap file location to protect against CVE-2017-1000382 > silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null you likely want to add a check if the directory exists, so that not every time Vim is called, it needs to shell out. Note, there is also `system()` available. See `:h isdirectory()` and `:h system()` > set directory=~/.vim/swap/ ,[ :h 'directory' ]- | - For Unix and Win32, if a directory ends in two path separators "//" | or "\\", the swap file name will be built from the complete path to | the file with all path separators substituted to percent '%' signs. | This will ensure file name uniqueness in the preserve directory. ` > This safely sets the swap file directory to a directory that should > not cause any security problems. For added security, the directory is > created so that only the owner has access to it, regardless of how the > system's umask or .swp file permissions are set. What is with files that are edited by several users possibly at the same time? They won't get a warning message now. > Additionally, the swap file collision (if you edit both ~/foo/file and > ~/bar/file at the same time) is not a major issue; Vim detects this > and gives the second swap file a different file extension. When you go > to restore from the swap file, you get a prompt asking which swap file > you want to use (if there are two swap files with the same basename), > which doesn't strike me as being terribly problematic. While this > approach may have some minor issues/quirks, for me it seems far > preferable to being vulnerable to this vulnerability. And how do you know from which swap file to recover? Additionally, if there is ~/.vim/swap/.foo.txt.swp and ~/.vim/swap/.foo.txt.swo and the first swap file is removed (after the editing session finishes), you won't get a swap file recovery message anymore when editing a file for which only ~/.vim/swap/.foo.txt.swo exists. > I have already applied this fix on Cucumber Linux and thought you may > want to consider applying a similar fix upstream. You might want to tweak your setting as mentioned above. Christian -- Die Welt ist eine Glocke, die einen Riss hat: Sie klappert, aber klingt nicht. -- Goethe, Maximen und Reflektionen, Nr. 333 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Thursday, November 2, 2017 at 9:09:49 AM UTC-4, Bram Moolenaar wrote: > Ken Takata wrote: > > > 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > > > Hanno Böck wrote: > > > > > > > I wanted to point out an issue here with vim swap files that make them > > > > a security problem. > > > > > > > > By default vim creates a file with the name .filename.swp in the same > > > > directory while editing. They contain the full content of the edited > > > > file. This usually gets deleted upon exit, but not if vim crashes or > > > > gets killed (e.g. due to a reboot). > > > > > > > > On web servers this can be a severe security risk. One can e.g. scan > > > > for web hosts that have swap files of PHP configuration files and thus > > > > expose settings like database passwords. (e.g. wget > > > > http://example.com/.wp-config.php.swp ) > > > > > > Why would a web server expose and serve such a file? That clearly is > > > the problem, not that Vim happens to create swap files (and undo and > > > backup files, depending on your configuration). > > > > > > You probably also create new files and copies of files that should not > > > be served. If you care about security, the web server must always use > > > whitelisting, only serve files that were intentionally made public. > > > > > > > In a scan of the alexa top 1 million I found ~750 instances of such > > > > files. I tried to inform affected people as best as I could. I also > > > > discovered such scans in my own web server logs, so I assume black hats > > > > are already aware of this and it's actively exploitet. > > > > > > > > I was wondering how to best avoid this on my own servers and I first > > > > thought about saving the swap files to tmp ( with "set directory"). > > > > However on multiuser systems this creates another security problem. > > > > These files are world readable, thus instead of leaking information to > > > > the world it's now leaking information to other users on the same > > > > system. Thus even if one is aware of the issue it's nontrivial to get > > > > secure settings (I've now worked around this by having per-user tmp > > > > dirs with secure permissions.) > > > > > > > > I think vim should change the behavior of swap files: > > > > 1. they should be stored in /tmp by default > > > > > > No, on Linux this is wiped clean on reboot. You lose your work on a > > > system crash. > > > > > > > 2. they should have secure permissions (tmp file security is > > > > a tricky thing and needs careful consideration to avoid symlink attacks > > > > and the like, but there are dedicated functions for this like mkstemp). > > > > > > The permissions are the same as the original file, and that is exactly > > > how it should be. > > > > > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > > > they shouldn't be called /tmp/.test.txt.swp, but more something > > > > like /tmp/.vim_swap.123782173) > > > > > > Infeasible, Vim can't find that file when trying to recover the original > > > file. > > > > An issue related to this (not the same) is filed as CVE-2017-1000382: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 > > https://security-tracker.debian.org/tracker/CVE-2017-1000382 > > > > It seems that the problem is that Vim ignores umask: > > http://www.openwall.com/lists/oss-security/2017/10/31/15 > > > > (Similar one for Emacs: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) > > This is working as intended, Vim does not use umask this way. > Umask is only used by simple commands such as cp, not by long running > processes that deal with many files. > > Problem is with the user expectations. > > -- > Permission is granted to read this message out aloud on Kings Cross Road, > London, under the condition that the orator is properly dressed. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// Hi, I'd like to add my two cents to this. I have reproduced this on Centos 6 and Cucumber Linux 1.0. We have established that the umask plays no role in the permissions on swap files; Vim creates its swap files with the same permissions as the file being edited. However, there is another problem with the swap file permissions that has not yet been discussed: when Vim creates swap files, the .swp file is created with the owner and group set to the user who is editing the file (hereafter referred to as the "editor") and the editor's primary group respectively. The permission bits on the swap file are the same as the original file. This is a problem, as the editor's primary group may be different from the group of the file being edited. Take /etc/shadow for example. That file is supposed to have the
Re: Security risk of vim swap files
* zdoh...@redhat.com[171102 10:36]: > can VIm provide a way how to set permissions for swap files? So users > which consider this VIm behavior as security risk can set permissions > differently? Would that be possible for VIm (like setting set > swap_file_perm=775 in vimrc file)? What security risk do you see? The original file and swap file are conceptually treated as one unit. If someone can do something to the original (such as writing), preventing that person from writing the swap file has absolutely no security benefit. The purpose of umask is to allow a newly created file to have specific permissions unset at time of creation, preventing a race condition between file creation and subsequently setting file permissions with chmod. With vim and a swap file, using umask to create the swap file with permissions more restrictive than the original does not prevent anyone from doing anything he or she can still do with the original. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Mi, 01 Nov 2017, Ken Takata wrote: > This makes Vim to respect umask when creating a swapfile. > (I'm not sure this is actually needed, though.) I am also not sure if this is needed. However it makes sense to have the swap file with the same permissions of the original file. Think of a crash of an editing session of a file that has o+rw set. In that case and with a restrictive umask of 0077 only the author could restore it, while currently everybody who is allowed to edit that file can also recover it. Christian -- Es kann so schön sein, alt zu werden, das Gefühl zu haben, das fast schon ein Glück ist, mehr von jenen Dingen zu wissen, an die man früher nicht einmal gedacht hat. Weil man angeblich keine Zeit hatte. -- Heinz Rühmann -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Hi Bram, can VIm provide a way how to set permissions for swap files? So users which consider this VIm behavior as security risk can set permissions differently? Would that be possible for VIm (like setting set swap_file_perm=775 in vimrc file)? -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Ken Takata wrote: > 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > > Hanno Böck wrote: > > > > > I wanted to point out an issue here with vim swap files that make them > > > a security problem. > > > > > > By default vim creates a file with the name .filename.swp in the same > > > directory while editing. They contain the full content of the edited > > > file. This usually gets deleted upon exit, but not if vim crashes or > > > gets killed (e.g. due to a reboot). > > > > > > On web servers this can be a severe security risk. One can e.g. scan > > > for web hosts that have swap files of PHP configuration files and thus > > > expose settings like database passwords. (e.g. wget > > > http://example.com/.wp-config.php.swp ) > > > > Why would a web server expose and serve such a file? That clearly is > > the problem, not that Vim happens to create swap files (and undo and > > backup files, depending on your configuration). > > > > You probably also create new files and copies of files that should not > > be served. If you care about security, the web server must always use > > whitelisting, only serve files that were intentionally made public. > > > > > In a scan of the alexa top 1 million I found ~750 instances of such > > > files. I tried to inform affected people as best as I could. I also > > > discovered such scans in my own web server logs, so I assume black hats > > > are already aware of this and it's actively exploitet. > > > > > > I was wondering how to best avoid this on my own servers and I first > > > thought about saving the swap files to tmp ( with "set directory"). > > > However on multiuser systems this creates another security problem. > > > These files are world readable, thus instead of leaking information to > > > the world it's now leaking information to other users on the same > > > system. Thus even if one is aware of the issue it's nontrivial to get > > > secure settings (I've now worked around this by having per-user tmp > > > dirs with secure permissions.) > > > > > > I think vim should change the behavior of swap files: > > > 1. they should be stored in /tmp by default > > > > No, on Linux this is wiped clean on reboot. You lose your work on a > > system crash. > > > > > 2. they should have secure permissions (tmp file security is > > > a tricky thing and needs careful consideration to avoid symlink attacks > > > and the like, but there are dedicated functions for this like mkstemp). > > > > The permissions are the same as the original file, and that is exactly > > how it should be. > > > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > > they shouldn't be called /tmp/.test.txt.swp, but more something > > > like /tmp/.vim_swap.123782173) > > > > Infeasible, Vim can't find that file when trying to recover the original > > file. > > An issue related to this (not the same) is filed as CVE-2017-1000382: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 > https://security-tracker.debian.org/tracker/CVE-2017-1000382 > > It seems that the problem is that Vim ignores umask: > http://www.openwall.com/lists/oss-security/2017/10/31/15 > > (Similar one for Emacs: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) This is working as intended, Vim does not use umask this way. Umask is only used by simple commands such as cp, not by long running processes that deal with many files. Problem is with the user expectations. -- Permission is granted to read this message out aloud on Kings Cross Road, London, under the condition that the orator is properly dressed. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Hi, 2017/11/1 Wed 12:32:43 UTC+9 Ken Takata wrote: > Hi, > > 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > > Hanno Böck wrote: > > > > > I wanted to point out an issue here with vim swap files that make them > > > a security problem. > > > > > > By default vim creates a file with the name .filename.swp in the same > > > directory while editing. They contain the full content of the edited > > > file. This usually gets deleted upon exit, but not if vim crashes or > > > gets killed (e.g. due to a reboot). > > > > > > On web servers this can be a severe security risk. One can e.g. scan > > > for web hosts that have swap files of PHP configuration files and thus > > > expose settings like database passwords. (e.g. wget > > > http://example.com/.wp-config.php.swp ) > > > > Why would a web server expose and serve such a file? That clearly is > > the problem, not that Vim happens to create swap files (and undo and > > backup files, depending on your configuration). > > > > You probably also create new files and copies of files that should not > > be served. If you care about security, the web server must always use > > whitelisting, only serve files that were intentionally made public. > > > > > In a scan of the alexa top 1 million I found ~750 instances of such > > > files. I tried to inform affected people as best as I could. I also > > > discovered such scans in my own web server logs, so I assume black hats > > > are already aware of this and it's actively exploitet. > > > > > > I was wondering how to best avoid this on my own servers and I first > > > thought about saving the swap files to tmp ( with "set directory"). > > > However on multiuser systems this creates another security problem. > > > These files are world readable, thus instead of leaking information to > > > the world it's now leaking information to other users on the same > > > system. Thus even if one is aware of the issue it's nontrivial to get > > > secure settings (I've now worked around this by having per-user tmp > > > dirs with secure permissions.) > > > > > > I think vim should change the behavior of swap files: > > > 1. they should be stored in /tmp by default > > > > No, on Linux this is wiped clean on reboot. You lose your work on a > > system crash. > > > > > 2. they should have secure permissions (tmp file security is > > > a tricky thing and needs careful consideration to avoid symlink attacks > > > and the like, but there are dedicated functions for this like mkstemp). > > > > The permissions are the same as the original file, and that is exactly > > how it should be. > > > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > > they shouldn't be called /tmp/.test.txt.swp, but more something > > > like /tmp/.vim_swap.123782173) > > > > Infeasible, Vim can't find that file when trying to recover the original > > file. > > An issue related to this (not the same) is filed as CVE-2017-1000382: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 > https://security-tracker.debian.org/tracker/CVE-2017-1000382 > > It seems that the problem is that Vim ignores umask: > http://www.openwall.com/lists/oss-security/2017/10/31/15 > > (Similar one for Emacs: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) How about the attached patch? This makes Vim to respect umask when creating a swapfile. (I'm not sure this is actually needed, though.) Regards, Ken Takata -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent 8a009ace74e43d2117cc4a17600b3de60ab08de4 diff --git a/src/fileio.c b/src/fileio.c --- a/src/fileio.c +++ b/src/fileio.c @@ -509,9 +509,16 @@ readfile( * (they must not write the swapfile). * Add the "read" and "write" bits for the user, otherwise we may * not be able to write to the file ourselves. + * Also respect umask. * Setting the bits is done below, after creating the swap file. */ - swap_mode = (st.st_mode & 0644) | 0600; + { + mode_t umask_save; + + umask_save = umask(0); /* Get current umask. */ + (void)umask(umask_save); + swap_mode = (st.st_mode & 0644 & ~umask_save) | 0600; + } #endif #ifdef FEAT_CW_EDITOR /* Get the FSSpec on MacOS
Re: Security risk of vim swap files
Hi, 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > Hanno Böck wrote: > > > I wanted to point out an issue here with vim swap files that make them > > a security problem. > > > > By default vim creates a file with the name .filename.swp in the same > > directory while editing. They contain the full content of the edited > > file. This usually gets deleted upon exit, but not if vim crashes or > > gets killed (e.g. due to a reboot). > > > > On web servers this can be a severe security risk. One can e.g. scan > > for web hosts that have swap files of PHP configuration files and thus > > expose settings like database passwords. (e.g. wget > > http://example.com/.wp-config.php.swp ) > > Why would a web server expose and serve such a file? That clearly is > the problem, not that Vim happens to create swap files (and undo and > backup files, depending on your configuration). > > You probably also create new files and copies of files that should not > be served. If you care about security, the web server must always use > whitelisting, only serve files that were intentionally made public. > > > In a scan of the alexa top 1 million I found ~750 instances of such > > files. I tried to inform affected people as best as I could. I also > > discovered such scans in my own web server logs, so I assume black hats > > are already aware of this and it's actively exploitet. > > > > I was wondering how to best avoid this on my own servers and I first > > thought about saving the swap files to tmp ( with "set directory"). > > However on multiuser systems this creates another security problem. > > These files are world readable, thus instead of leaking information to > > the world it's now leaking information to other users on the same > > system. Thus even if one is aware of the issue it's nontrivial to get > > secure settings (I've now worked around this by having per-user tmp > > dirs with secure permissions.) > > > > I think vim should change the behavior of swap files: > > 1. they should be stored in /tmp by default > > No, on Linux this is wiped clean on reboot. You lose your work on a > system crash. > > > 2. they should have secure permissions (tmp file security is > > a tricky thing and needs careful consideration to avoid symlink attacks > > and the like, but there are dedicated functions for this like mkstemp). > > The permissions are the same as the original file, and that is exactly > how it should be. > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > they shouldn't be called /tmp/.test.txt.swp, but more something > > like /tmp/.vim_swap.123782173) > > Infeasible, Vim can't find that file when trying to recover the original > file. An issue related to this (not the same) is filed as CVE-2017-1000382: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 https://security-tracker.debian.org/tracker/CVE-2017-1000382 It seems that the problem is that Vim ignores umask: http://www.openwall.com/lists/oss-security/2017/10/31/15 (Similar one for Emacs: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) Regards, Ken Takata -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Hanno Böck wrote: > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) Why would a web server expose and serve such a file? That clearly is the problem, not that Vim happens to create swap files (and undo and backup files, depending on your configuration). You probably also create new files and copies of files that should not be served. If you care about security, the web server must always use whitelisting, only serve files that were intentionally made public. > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default No, on Linux this is wiped clean on reboot. You lose your work on a system crash. > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). The permissions are the same as the original file, and that is exactly how it should be. > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) Infeasible, Vim can't find that file when trying to recover the original file. -- BEDEVERE: Oh! LAUNCELOT: No "Arrggghhh ... " at the back of the throat. BEDEVERE: No! "Oh!" in surprise and alarm! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Di, 31 Okt 2017, Hanno Böck wrote: > Hi, > > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) > > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) It is true, that this can cause a problem. However, I am not sure its correct to blame vim here. First, I think you need to configure your webserver to be able to view dotfiles. I believe a default installation of at least apache won't let you show dotfiles. Second, I wonder why those swapfiles are not deleted. Somehow Vim must have crashed or be killed and in that case one certainly don't want that the swapfiles are deleted (think of recovery). Finally, using git for managing your document root, can show you those rubbish swap files, since the directory is not clean than, if you really need to edit your files on the server directly and do not use a deployment of some kind. One could argue, that swap files should be stored below ~/.vim directory tree. But what if several users edit the same file? One also needs to make sure, the path would be encoded into the name, but then we might run into trouble with filename length limitations. So I think it in the users responsibility to configure Vim correctly (check the directory option) to not have him litter his document root with old swap files. The best I can think of currently, is to add a warning to the documentation, that swapfiles may cause a security problem. Christian -- "Wenn man alle Gesetze studieren sollte, so hätte man gar keine Zeit, sie zu übertreten." -- Goethe, Maximen und Reflektionen, Nr. 347 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, Oct 31, 2017 at 6:30 AM, Hanno Böckwrote: > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) > But Vim needs to know which swapfile is associated with which non-swap file. How can it do that, other than by having the swapfile's name contain the original file's name? Anyway I don't think it's Vim's job to cover up for foolish admins. -Manny -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Hanno Böck[171031 06:32]: > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) See the 'directory' option. I don't see this as a problem with Vim; Vim gives the user appropriate means to avoid it. The problem is one or both of (1) a web server that serves files that the admin did not intend to serve and (2) the admin's Vim configuration that puts temporary files in a location that the web server serves without appropriate filtering. Both problems are fixable with appropriate configuration. It would be inappropriate for Vim's default to be to assume that having both the file being edited and its swap file in the same directory would be a security issue. The implication is that in most cases, if someone can read the swap file, they can also read the original. This happens to not always be true in the case of a web server that filters the PHP configuration files but not Vim's swap files in the same directory. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, 31 Oct 2017 11:59:41 +0100 Tony Mechelynckwrote: > Isn't /tmp deleted at every bootup? If it is, or on the systems where > it is, this makes it useless for files whose chief utility is to allow > recovery after a program or system crash. That is an interesting point, however this is not unified among systems. An alternative would be to place them in a location like ~/.vim > IMHO, the kind of considerations in Herrn Böcks message should not be > handled at Vim level but at the level of system security in general. > In particular neither system configuration files, nor files containing > passwords or the backups of such files, nor "invisible" files (whose > names start with a dot) — and this includes Vim swapfiles — should > IMHO be visible to the lambda web user. This seems quite vague and more like trying to discuss the issue away instead of solving it. Can you be more specific what you have in mind? It sounds like you expect from web servers to generally block access to dot files. However that won't work, as there are standardized locations on web servers i dot files (e.g. .well-known URLs, part of a couple of modern standards). So how should that specifically work while not breaking existing things? And who exactly should solve it in what way? > Whether a privileged login > should be allowed from a remote console is for every sysadmin to weigh > seriously, with consideration of the particular system's requirements. > On my machine I don't allow any remote login, and I don't open (other > than in "view source" mode) emails from dubious sources, but of course > other systems have other requirements: it is not always practical to > require that privileged logins should be allowed only from one > particular keyboard and screen located in the head office computer > room, to which only a few select operators (or BOFHs) are allowed > entry. Sorry, can you explain what this part has to do with the problem? Because I see no connection whatsoever. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, Oct 31, 2017 at 11:30 AM, Hanno Böckwrote: > Hi, > > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) > > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) > > -- > Hanno Böck > https://hboeck.de/ Isn't /tmp deleted at every bootup? If it is, or on the systems where it is, this makes it useless for files whose chief utility is to allow recovery after a program or system crash. IMHO, the kind of considerations in Herrn Böcks message should not be handled at Vim level but at the level of system security in general. In particular neither system configuration files, nor files containing passwords or the backups of such files, nor "invisible" files (whose names start with a dot) — and this includes Vim swapfiles — should IMHO be visible to the lambda web user. Whether a privileged login should be allowed from a remote console is for every sysadmin to weigh seriously, with consideration of the particular system's requirements. On my machine I don't allow any remote login, and I don't open (other than in "view source" mode) emails from dubious sources, but of course other systems have other requirements: it is not always practical to require that privileged logins should be allowed only from one particular keyboard and screen located in the head office computer room, to which only a few select operators (or BOFHs) are allowed entry. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Security risk of vim swap files
Hi, I wanted to point out an issue here with vim swap files that make them a security problem. By default vim creates a file with the name .filename.swp in the same directory while editing. They contain the full content of the edited file. This usually gets deleted upon exit, but not if vim crashes or gets killed (e.g. due to a reboot). On web servers this can be a severe security risk. One can e.g. scan for web hosts that have swap files of PHP configuration files and thus expose settings like database passwords. (e.g. wget http://example.com/.wp-config.php.swp ) In a scan of the alexa top 1 million I found ~750 instances of such files. I tried to inform affected people as best as I could. I also discovered such scans in my own web server logs, so I assume black hats are already aware of this and it's actively exploitet. I was wondering how to best avoid this on my own servers and I first thought about saving the swap files to tmp ( with "set directory"). However on multiuser systems this creates another security problem. These files are world readable, thus instead of leaking information to the world it's now leaking information to other users on the same system. Thus even if one is aware of the issue it's nontrivial to get secure settings (I've now worked around this by having per-user tmp dirs with secure permissions.) I think vim should change the behavior of swap files: 1. they should be stored in /tmp by default 2. they should have secure permissions (tmp file security is a tricky thing and needs careful consideration to avoid symlink attacks and the like, but there are dedicated functions for this like mkstemp). 3. Ideally they also shouldn't leak currently edited filenames (e.g. they shouldn't be called /tmp/.test.txt.swp, but more something like /tmp/.vim_swap.123782173) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Security risk of vim swap files
Hi, I wanted to point out an issue here with vim swap files that make them a security problem. By default vim creates a file with the name .filename.swp in the same directory while editing. They contain the full content of the edited file. This usually gets deleted upon exit, but not if vim crashes or gets killed (e.g. due to a reboot). On web servers this can be a severe security risk. One can e.g. scan for web hosts that have swap files of PHP configuration files and thus expose settings like database passwords. (e.g. wget http://example.com/.wp-config.php.swp ) In a scan of the alexa top 1 million I found ~750 instances of such files. I tried to inform affected people as best as I could. I also discovered such scans in my own web server logs, so I assume black hats are already aware of this and it's actively exploitet. I was wondering how to best avoid this on my own servers and I first thought about saving the swap files to tmp ( with "set directory"). However on multiuser systems this creates another security problem. These files are world readable, thus instead of leaking information to the world it's now leaking information to other users on the same system. Thus even if one is aware of the issue it's nontrivial to get secure settings (I've now worked around this by having per-user tmp dirs with secure permissions.) I think vim should change the behavior of swap files: 1. they should be stored in /tmp by default 2. they should have secure permissions (tmp file security is a tricky thing and needs careful consideration to avoid symlink attacks and the like, but there are dedicated functions for this like mkstemp). 3. Ideally they also shouldn't leak currently edited filenames (e.g. they shouldn't be called /tmp/.test.txt.swp, but more something like /tmp/.vim_swap.123782173) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.