First the security. Any insight on when this security flaw be fixed? I'ts CVE-2017-14396 (SQL injection) which was reported 3 months ago. Seems to me it's important. Or is there a patch available for it?Attachment question.I've seen that new attachment in the attachment directory (if you store attachment in the filebase and not the database) will be created like this:d-wxr-xr-t  2 user user 4.0K 2017-12-17 15 aand so on.But why world readable? I don't mind the sticky bit, but why are these folders made world readable?Or is that because my directory is 755 and they won't be created world readable anymore if I chmod the attachment directory to 750?If it can't be done this way, what's the best htaccess content so only logged in customer, agent and osticket can read the attachment?We don't need world access since we're using mod_ruid2.

That security vulnerability was fixed in 1.10.1 so the fix was released within 24 hours judging by the timestamps.

Ah I'm sorry, I was looking at multiple vulnerabilities. The CVE-2017-14396 was indeed fixed.In 1.10.1 there are CVE-2017-15362 and CVE-2017-15580, however, a malicious user must be logged in to be able to abuse these.14396 was more dangerous but I mixed up the version numbers.Any thoughts on question (or if it's made by design) suggestion 2?

There does not seem to be any reference to changing the chmod but theres a comment about it: https://github.com/osTicket/osTicket-plugins/blob/develop/storage-fs/storage.php#L52

@[deleted]01 is right, CVE-2017-14396 was fixed in v1.10.1.

"In 1.10.1 there are CVE-2017-15362 and CVE-2017-15580, however, a malicious user must be logged in to be able to abuse these."For CVE-2017-15580, this isn't really an issue as we scan/check every file's extension, mime-type, size, etc. to ensure the file is what it says it is. If anything is mismatched with the exif data then we deny the file. As of now, we have no way of scanning an entire file and ensuring that all contents within it is "safe". We are actively looking into ways we can accomplish this though."In 1.10.1 there are CVE-2017-15362 and CVE-2017-15580, however, a malicious user must be logged in to be able to abuse these."As for CVE-2017-15362, the guy who reported this vulnerability to us gave little to no information on how he accomplished the XSS'ing. I tried and tried to replicate what he said was vulnerable but could not accomplish it. With this being said I'm no 1337 hacker so it could be possible. Still trying to get info from him lol"Any thoughts on question (or if it's made by design) suggestion 2?"The line that @[deleted]01 referenced states: // TODO: Consider CHMOD on the fileThis means that we haven't gotten to this yet and it's still under consideration/discussion.Thanks for the reports/concerns. Cheers.

Thank you for your answer Kevin.I did not see the two mentioned CVE's as real thread for ourselves since a user has to be logged in for that and we only allow customers in.Also I know that a "todo" means it's being work in progress which is not done yet.But thank you for the confirmation and clarification.

2 years later

What's up with these CVE's, are they already covered? where can we find information about it?

Write a Reply...