RustPython type imports via mutable modules can lead to type confusion

[davidhewitt]

In #5995 we introduced code such as the following to implement types on the RustPython API:

#[cfg(RustPython)]
pyobject_native_type!(
    PyDict,
    ffi::PyDictObject,
    |py| {
        static TYPE: PyOnceLock<Py<PyType>> = PyOnceLock::new();
        TYPE.import(py, "builtins", "dict").unwrap().as_type_ptr()
    },
    "builtins",
    "dict",
    #checkfunction=ffi::PyDict_Check
);

Unfortunately, it's possible for hostile code to reassign builtins.dict to another type before importing PyO3 modules. While such an assignment is generally nonsensical, it could open a security issue: as long as PyO3 is trusting the imported type to be bedict, I think we're theoretically susceptible to memory corruption if we assume the layout of dict anywhere in code dependent on this imported type.

I guess we should audit where we assume memory layout of native types based on the type pointer, and perhaps disable them under the #[cfg(RustPython)] branches?

cc @bschoenmaeckers

(Credit to Codex security scanning for this discovery.)

[bschoenmaeckers]

Interesting, we could populate the OnceLock using a different way, that avoids the builtins module.

One way of getting the type object could be: Py_TYPE(PyDict_New()) (ignoring ref counts)

[bschoenmaeckers]

That said, when compiling for RustPython we should not touch any objects directly. So I think we should not be using PyDictObject directly, and remove the usage of PyDictObject in this situation.