> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Philip > Prindeville > Sent: Tuesday, 13 September, 2022 14:17 > > I'm working on a bug in an application where the application config is given > the directory path in which to find a key-store, which it then loads. > > My issue is this: a regular UNIX file is trivial to handle (make sure it's > owned by "root" or the uid that the app runs at, and that it's 0600 or 0400 > permissions... easy-peasy). > > But what happens when the file we encounter is a symlink? You read the target. What's the problem? > If the symlink is > owned by root but the target isn't, or the target permissions aren't 0600 0r > 0400... So what? You can use lstat if you're really worried about symlinks, but frankly I'm not seeing the vulnerability, at least at first blush. What's the threat model? This is reading a private key, not writing one, so there's no exfiltration issue simply from reading the file. Suppose an attacker replaces the private key file, or the contents of the file. So what? Either the attacker is in a privileged position and so can satisfy your ownership and permissions checks; or the attacker isn't, and ... you read a private key that either is the correct one (i.e. corresponds to the public key in the certificate), and so there's no problem; or it isn't, and you can't use the certificate, and you fail safe. Is this check meant to alert an administrator to a possibly-compromised, or prone-to-compromise, private key? Because if so, 1) it's too late, 2) a privileged attacker can trivially prevent it, and 3) why is that your job anyway? It's also not clear to me why symbolic links are toxic under your threat model. It's entirely possible I'm missing something here, but my initial impression is that these checks are of little value anyway. Can you explain what problem you're trying to solve? -- Michael Wojcik
