office-gobmx/stoc
Stephan Bergmann 9074f5602a tdf#148063: Avoid dereferencing potentially bad user-supplied TypeDescription
...from Basic script

> sub foo
>   a = Array()
>   oUnoValue = CreateUnoValue( "[]", a )
> end sub

at

> Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
> 0x00007fffc413b2db in stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo (this=0x3269200, rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at stoc/source/typeconv/convert.cxx:537
> 537	                reinterpret_cast<typelib_IndirectTypeDescription *>(aDestTD.get())->pType );
> (gdb) bt
> #0  0x00007fffc413b2db in stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo(com::sun::uno::Any const&, com::sun::uno::Type const&) (this=0x3269200, rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at stoc/source/typeconv/convert.cxx:537
> #1  0x00007fffc413d144 in non-virtual thunk to stoc_tcv::(anonymous namespace)::TypeConverter_Impl::convertTo(com::sun::uno::Any const&, com::sun::uno::Type const&) () at instdir/program/libstocserviceslo.so
> #2  0x00007ffff4fe0264 in convertAny(com::sun::uno::Any const&, com::sun::uno::Type const&) (rVal=uno::Any("[]any": empty uno::Sequence), aDestType=invalid uno::Type) at basic/source/classes/sbunoobj.cxx:324
> #3  0x00007ffff4fdfe79 in RTL_Impl_CreateUnoValue(SbxArray&) (rPar=...) at basic/source/classes/sbunoobj.cxx:4157
> #4  0x00007ffff513b1b0 in SbRtl_CreateUnoValue(StarBASIC*, SbxArray&, bool) (rPar=...) at basic/source/runtime/methods1.cxx:1403
> #5  0x00007ffff50ea80e in SbiStdObject::Notify(SfxBroadcaster&, SfxHint const&) (this=0x2003400, rBC=..., rHint=...) at basic/source/runtime/stdobj.cxx:1059
> #6  0x00007ffff3decfae in SfxBroadcaster::Broadcast(SfxHint const&) (this=0x3329e90, rHint=...) at svl/source/notify/SfxBroadcaster.cxx:39
> #7  0x00007ffff518e772 in SbxVariable::Broadcast(SfxHintId) (this=0x31e8f60, nHintId=SfxHintId::BasicDataWanted) at basic/source/sbx/sbxvar.cxx:151
> #8  0x00007ffff5186d4f in SbxValue::SbxValue(SbxValue const&) (this=0x31ff450, vtt=0x7ffff51ae718 <VTT for SbxMethod+16>, r=...) at basic/source/sbx/sbxvalue.cxx:66
> #9  0x00007ffff518d291 in SbxVariable::SbxVariable(SbxVariable const&) (this=0x31ff450, vtt=0x7ffff51ae710 <VTT for SbxMethod+8>, r=...) at basic/source/sbx/sbxvar.cxx:45
> #10 0x00007ffff517d44a in SbxMethod::SbxMethod(SbxMethod const&) (this=0x31ff450, r=...) at basic/source/sbx/sbxobj.cxx:838
> #11 0x00007ffff510386b in SbiRuntime::FindElement(SbxObject*, unsigned int, unsigned int, ErrCode, bool, bool) (this=0x2d6f400, pObj=0x2003400, nOp1=32773, nOp2=9, nNotFound=..., bLocal=false, bStatic=false) at basic/source/runtime/runtime.cxx:3709
> #12 0x00007ffff50f5a91 in SbiRuntime::StepRTL(unsigned int, unsigned int) (this=0x2d6f400, nOp1=32773, nOp2=9) at basic/source/runtime/runtime.cxx:4131
> #13 0x00007ffff50faef8 in SbiRuntime::Step() (this=0x2d6f400) at basic/source/runtime/runtime.cxx:830
[...]

Change-Id: I552f0360aaf3f9aa6a499aa5ea6eca9ae37e4614
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131739
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-18 15:33:50 +01:00
..
source
test
util
CppunitTest_stoc_uriproc.mk
IwyuFilter_stoc.yaml
Library_bootstrap.mk
Library_introspection.mk
Library_invocadapt.mk
Library_invocation.mk
Library_javaloader.mk
Library_javavm.mk
Library_namingservice.mk
Library_proxyfac.mk
Library_reflection.mk
Library_stocservices.mk
Makefile
Module_stoc.mk
README.md
unosdk.mk

Registries, Reflection, Introspection Implementation for UNO

The UNO types and services bootstrapping code is very old, and concepts are tightly knit together. Whenever you want to change something you risk backwards incompatibility. The code causes mental pain, and whenever you need to touch it you want to run away screaming. One typically ends up doing minimally invasive changes. That way, you have a chance of surviving the process. But you also pile up guilt.

At the heart of the matter there is the old binary "store" file structure and the XRegistry interface on top of it. At runtime, both all the UNO type information (scattered across a number of binary .rdb files) and all the UNO service information (scattered across a number of .rdb files that used to be binary but have been mostly changed to XML now) are represented by a single XRegistry instance each.

The way the respective information is represented in the XRegistry interface simply corresponds to the way the information is stored in the binary .rdb files. Those files are designed for storage of hierarchically nested small blobs of information. Hence, for example information about a UNO interface type com.sun.star.foo.XBar is stored in a nested "folder" with path com - sun - star - foo - XBar, containing little blobs of information about the type's ancestors, its methods, etc. Similarly for information about instantiable services like com.sun.star.baz.Boz.

As there are typically multiple .rdb files containing types resp. services (URE specific, LO specific, from extensions, ...), but they need to be represented by a single XRegistry instance, so "nested registries" were invented. They effectively form a linear list of chaining XRegistry instances together. Whenever a path needs to be looked up in the top-level registry, it effectively searches through the linear list of nested registries. All with the cumbersome UNO XRegistry interface between the individual parts. Horror.

When the XML service .rdbs were introduced, we chickened out (see above for rationale) and put them behind an XRegistry facade, so that they would seamlessly integrate with the existing mess. We postponed systematic clean-up to the pie-in-the-sky days of LibreOffice 4 (or, "once we'll become incompatible with OpenOffice.org," as the phrase used to be back then)