Hi fellow LTS contributors
I have started to look into CVE-2019-10784 for phppgadmin.
After some thinking on how it would be possible to protect against this I'm starting to think about whether we really want to protect against this, and whether it is in fact possible at all?
I have ideas on how we can reduce the attack possibilities but I cannot find any perfect solution to this.
What we can do is to check that the User Agent provided Referrer string points to the location where it is installed. There are however a few disadvantages with this.
1) It relies on that the user agent always provide the referrer string. A problem is that it is an optional header.
2) I think there are situations where "-" is used as the referrer string and if we allow that the check is quite pointless.
I do not think this is a way forward.
An alternative way is to generate some temporary approval code that needs to be provided in the next request. But there are disadvantages with that too.
1) We may end up in the situation where the admin can just have one browser tab open. That is highly inconvenient.
2) We cannot use cookies (since it would survive being passed through the attacker trick site) making it a little more fault prone.
3) They need to be limited in life time to not waste too much database space, making it less practical.
I think the idea of some kind of temporary approval code is the way to go, but we probably need to accept quite a few of them and will quite likely require quite some changes to the software.
Do we think it is worth the effort to do this in oldoldstable?
I would say that it is a stretch that someone can actually make use of this in practice. There are quite a few things that must be in place at the same time.
1) The target admin must be logged in to the target service.
2) The attacker must know the target service and know that the target admin.
3) The attacker must trick the target admin to visit some page that (using some _javascript_) post to the target service.
This is really a targeted attack. Sure possible, but it is not the most likely attack either.
I checked phpmyadmin. It has checks against direct call from command prompt but I could not find any such prevention code for this case. So I guess it is just as vulnerable.
I guess other site software is also vulnerable.
Is it worth fixing?
Best regards
// Ola
--
--- Inguza Technology AB --- MSc in Information Technology ----
---------------------------------------------------------------