Isn't Ubuntu's system prompt for my password spoofable?
Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect.
Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard that the recent generation of Windows is more terminal-friendly). In particular, Linux convention does a better job of sandboxing apps into users, while in Windows anything important runs as System, while the Linux GUI (X Server) sucks at security, and the Windows GUI has fancy things like UAC built-in. Basically, Linux is (and always has been) a server first and a workstation second, while Windows is the other way around.
Security Models
As far as "the OS" (ie the kernel) is concerned, you have 7 tty consoles and any number of SSH connections (aka "login sessions") - it just so happens that ubuntu ships with scripts to auto-start the GUI on the tty7 session, but to the kernel it's just another application.
Login sessions and user accounts are sandboxed quite nicely from each other, but Linux takes a security mindset that you don't need to protect a user from them-self. In this security model, if your account gets compromised by malware then it's a lost cause, but we still want to isolate it from other accounts to protect the system as a whole.
For example, Linux apps tend to create a low-privilege user like apache or ftp that they run as when not needing to do rooty things. If an attacker manages to take control of a running apache process, it can muck up other apache processes, but will have troubles jumping to ftp processes.
Note that Windows takes a fundamentally different approach here, largely through the convention that all important things run as System all the time. A malicious service in Linux has less scope to do bad things than a malicious process running as System, so Windows needs to go to extra efforts to protect someone with admin rights from "them-self".
GUI environments and an X Server that was not designed for security throw a wrench into this security model.
Gnome gksudo vs Windows UAC, and keyloggers
In Windows, when a user-process requests privilege escalation, the kernel throws up a special protected prompt whose memory and keyboard / mouse bus is isolated from the rest of the rest of the desktop environment. It can do this because the GUI is built-in to the OS. In Linux, the GUI (X server) is just another application, and therefore the password prompts belong to the process that invoked them, running as you, sharing memory permissions and an input bus with every other window and process running as you.
The root prompt can't do the fancy UAC things Iike lock the keyboard because those either need to be root already, or require totally re-designing the X server (see Wayland below). A catch-22 that in this case is a downside of separating the GUI from the kernel. But at least it's in keeping with the Linux security model.
If we were to revise the security model to clamp down on this by adding sandboxing between password prompts and other processes running as the user in the same GUI session, we could have to re-write a great many things. At the least, the kernel would need to become GUI aware such that it is capable of creating prompts (not true today). The other go-to example is that all processes in a GUI session share a keyboard bus.
Watch me write a keylogger and then press some keys in a different window:
➜ ~ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech K400 Plus id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
➜ ~ xinput test 9
key release 36
key press 44
hkey release 44
key press 40
ekey release 40
key press 33
lkey release 33
key press 33
lkey press 39
okey release 33
key release 39
key press 66
key press 31
Any process running as you can sniff the password in another process's prompt or terminal and then call sudo on itself (this follows directly from the "no need to protect you from you" mindset), so increasing the security of the password prompts is useless unless we fundamentally change the security model and do a massive re-write of all sorts of things.
(it's worth noting that Gnome appears to at least sandbox the keyboard bus on the lock screen and new sessions through "Switch Users" as things typed there do not show up in my session's keyboard bus)
Wayland
Wayland is a new protocol that aims to replace X11. It locks down client applications so that they cannot steal information or affect anything outside of their window. The only way the clients can communicate with each other outside of exterior IPC is by going through the compositor which controls all of them. This doesn't fix the underlying problem however, and simply shifts the need for trust to the compositor.
Virtualization and Containers
If you work with cloud technologies, you're probably jumping up and down saying "Docker is the answer!!". Indeed, brownie points for you. While Docker itself is not really intended to enhance security (thanks @SvenSlootweg), it does point to using containerization and / or virtualization as a forward that's compatible with the current Linux architecture.
Two notable linux distributions that are built with inter-process isolation in mind:
Qubes OS that runs user-level apps inside multiple VMs separated into "security domains" such as work, banking, web browsing.
Android that installs and runs each app as a separate low-privilege user, thus gaining process-level isolation and file-system isolation (each app is confined to its own home directory) between apps.
Bottom Line: From the perspective of an end-user, it's not unreasonable to expect Linux to behave the same way as Windows, but this is one of those cases where you need to understand a bit about how the underlying system works and why it was designed that way. Simply changing the implementation of the password prompts will not accomplish anything so long as it is owned by a process owned by you. For Linux to get the same security behaviours as Windows in the context of a single-user GUI workstation would require significant re-design of the OS, so it's unlikely to happen, but things like Docker may provide a way forward in a more Linux-native way.
In this case, the important difference is that Linux is designed at the low level to be a multi-user server and they make the decision not to protect a user from them-self, while Windows is designed to be a single-user workstation, so you do need to have inter-process protections within a login session. It's also relevant that in Windows the GUI is part of the OS, while in Linux the GUI is just another user-level application.
Is there any safety mechanism in Linux in general or Ubuntu specifically which prevents any application from displaying a dialog which looks identical to the system's one, asking me for my password?
Quick answer: No.
From the perspective of the user, there is no guarantee that the prompt comes from the operating system; it could be any malicious program which had only a limited permission to show a window, and by prompting for my password, will gain unlimited access to the entire machine.
If a malicious program is on the computer, it doesn't even matter what program is showing the dialog.
If it is the malicious program, well, as described in the next sentence, it doesn't even need to show you a dialog. If it is a legit program, the malicious program can "watch" the window and what you're typing there, in X server environments (the terminal is better).
Solution?
If you have reason to believe some program isn't trustworthy, sandboxing (VM or lesser things).
Else, not asking for passwords. That dialog is convenience for non-technical users. If you're concerned for security, or an organizations admin or similar, there's absoluetly no need to ever display a GUI password query. Configure the permissions of non-root user accounts properly (yes or no, but not asking), and do not use a desktop as root (because of that, and because it is an temptation to use root more often than necessary).
By prompting the user for password regularly, the system teaches the user that giving his system password whenever some application asks for it is a perfectly natural thing to do.
As described, just don't ask them. As admin, "your" users are supposed to have clearly defined permissions.
And, about auto updates as organization admin: Are you insane :) Seriously, don't let many Ubuntu clients update randon things at random times. How about central images that are maintained and tested by you and then rolled out; or in the other direction things like Ansible?
Completely independent of security, updates may break things. That's why.
Yes. This is insecure!
I personally always Cancel that dialog. Not because it could be fake, but because it could be real.
I am supposed to give escalated privileges to "an application" just because it asks? No, I don't think so.
System updates are fine, I do those manually, but it annoys me that the error reporting system requires this. Bad design.