Denial of Service with chances of information leakage

[dcRUSTy]

Describe the bug
Talisman apparently follows symlinks while scanning. If a malicious git repository has symlink committed in one of the commits Say on
*nix - symlink to /dev/urandom (Infinite size file?) or /dev/random (super slow never ending file)
Windows - symlink to malicious remote SMB server

On *nix it will lead to atleast DoS as /dev/urandom is never ending?
On Windows User Credential leakage as Windows will try to login to remote SMB share with current user credentials then DoS also possible. These leaked credentials may open other portals of exploitation.

On windows it depends on value of core.symlinks in git config

To Reproduce
Steps to reproduce the behavior:

1. Create a symlink to /dev/random . and add commit to to the repo.
2. Run talisman -s

Expected behavior
Should not follow symlink atleast outside of repo directory( or none at all?)
On *nix - Scan should complete in finite time
On Windows - Should not connect to remote server and should complete in finite time

Screenshots

it will be stuck forever

Additional context
Also applicable to precommit hooks for .talismanrc file. Again these are worst cases, highlighting core problem SYMLINKS Couldn't test all the scenarios kind of short on computational power.

[svishwanath-tw]

I'm thinking following symlinks to files outside the repository (eg: /dev/null) should be disregarded (not scanned) should be avoided, but following symlinks within the repo should be okay.

Any thoughts on that ?

[dcRUSTy]

I also thought the same...

but then...

Symlinks inside repo which point to already committed(git added) file will lead to 1 file being scanned twice and symlinks itself cannot hold anything secret(unless somebody obfuscates secret as a path in symlink)

And following symlinks in repo may create further chances of exploitation by symlink chaining (A->B->/dev/null) or even worse (Not sure if it is posssible) (A->B->A->B->A............) where both A and B are inside repo. 😅

[dcRUSTy]

Any update on this? This bug is equally serious.... Instead of
User asking Talisman to scan a Repo......
here
Repo can indirectly ask Talisman to Scan user(example - .bash_history or .zsh_history) via symlinks for secrets...

Tried reporting something similiar on talisman-maintainers@thoughtworks.com .... Has anybody received that?

[harinee]

Hi @dcRUSTy thanks for this bug and the mail you sent. We acknowledge and will triage the bug.