5 ms·

> “COBOL doesn’t present any security problems because it doesn’t really talk to any resources,” Malik said. “It just says ‘read’ or ‘write.’” Can someone know

> “COBOL doesn’t present any security problems because it doesn’t really talk to any resources,” Malik said. “It just says ‘read’ or ‘write.’” Can someone knowledgeable of COBOL expand on this? It sounds... not quite right, like it's missing some surrounding context. I feel like plenty of C's common security problems could be boiled down to "just reads and writes".

jussij 6y ago
I could be wrong here so others can correct my errors as required. My take of that comment is COBOL is very popular on mainframe systems and those mainframe system work around the concept of transactional batch processing. Processing is done in batches and the batches are control bay a transaction manager (i.e. CICS for example). In that model a COBOL program is just a step in the processing and is fully controlled the transaction manager. So in that sense it does just read and write data as one step in a much bigger batch of steps. As such the security is handled by the transaction manager layer.
Aloha 6y ago
COBOL on System/Z doesnt even know how to do file I/O, you set up the I/O in the JCL job that loads the COBOL application.
- p_l 6y ago
  That's just the default way of handling I/O on MVS descendants, but it's not the only one - pretty sure you can allocate and configure new "file open records", but it would make your program less portable ;) and there's rarely a need.
- rbanffy 6y ago
  The very concept of files is alien. You have datasets that look like card stacks or tapes. You don’t expect files and directories on machines that predate disks.
nulbyte 6y ago
I see two problems with such a claim. First, a practical one: COBOL programs can call external functions[0]. Second, a theoretical one: Even if a given program does not call external functions, they often read data written by other programs and write data read by other programs. The security implications seem obvious; a bug in a COBOL program can cause undesirable consequences outside of the program. [0]: https://www.ibm.com/docs/en/zos/2.1.0?topic=cbcc-calling-between-c-cobol https://www.ibm.com/docs/en/zos/2.1.0?topic=cbcc-calling-bet...
bawolff 6y ago
I don't know anything about cobol, but its not uncommon to try and sandbox a c program (e.g. with seccomp) so it can do a limited number of things such as read and write from a few file descriptors, with the hope that if its compromised, there is nothing interesting to do if you don't have the rights to make any system calls, etc. Of course there will always be security flaws, anyone who says otherwise is probably trying to sell you something, but reducing attack surface is a good risk mitigation strategy if done correctly.
davidedp 6y ago
Walk in in a COBOL practitioners' conventicle and whisper "Y2K", and then run away as far as you can ;-)

jussij 6y ago

I could be wrong here so others can correct my errors as required. My take of that comment is COBOL is very popular on mainframe systems and those mainframe system work around the concept of transactional batch processing. Processing is done in batches and the batches are control bay a transaction manager (i.e. CICS for example). In that model a COBOL program is just a step in the processing and is fully controlled the transaction manager. So in that sense it does just read and write data as one step in a much bigger batch of steps. As such the security is handled by the transaction manager layer.

Aloha 6y ago

COBOL on System/Z doesnt even know how to do file I/O, you set up the I/O in the JCL job that loads the COBOL application.

p_l 6y ago
That's just the default way of handling I/O on MVS descendants, but it's not the only one - pretty sure you can allocate and configure new "file open records", but it would make your program less portable ;) and there's rarely a need.
rbanffy 6y ago
The very concept of files is alien. You have datasets that look like card stacks or tapes. You don’t expect files and directories on machines that predate disks.

nulbyte 6y ago

I see two problems with such a claim. First, a practical one: COBOL programs can call external functions[0]. Second, a theoretical one: Even if a given program does not call external functions, they often read data written by other programs and write data read by other programs. The security implications seem obvious; a bug in a COBOL program can cause undesirable consequences outside of the program. [0]: https://www.ibm.com/docs/en/zos/2.1.0?topic=cbcc-calling-between-c-cobol https://www.ibm.com/docs/en/zos/2.1.0?topic=cbcc-calling-bet...

bawolff 6y ago

I don't know anything about cobol, but its not uncommon to try and sandbox a c program (e.g. with seccomp) so it can do a limited number of things such as read and write from a few file descriptors, with the hope that if its compromised, there is nothing interesting to do if you don't have the rights to make any system calls, etc. Of course there will always be security flaws, anyone who says otherwise is probably trying to sell you something, but reducing attack surface is a good risk mitigation strategy if done correctly.

davidedp 6y ago

Walk in in a COBOL practitioners' conventicle and whisper "Y2K", and then run away as far as you can ;-)