sábado, 5 de abril de 2025

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

Bellacosa Mainframe e os perigos na gestão de memoria no mainframe

☕💥 Buffer Overflow, Memory Overwrite e Storage Corruption no z/OS

Ou como um simples MOVE pode transformar um datacenter multimilionário em uma sessão espírita conduzida por um Sysprog com café frio

Introdução

Existe uma frase antiga entre veteranos de Mainframe:

"Computadores não cometem erros. Eles apenas obedecem ordens idiotas em velocidades absurdamente altas."

E poucas coisas representam melhor isso do que três monstros ancestrais da programação:

Buffer Overflow
Memory Overwrite
Storage Corruption

O curioso é que muitos desenvolvedores COBOL juniores acreditam que isso é um problema de C, C++, Linux ou Windows.

Na verdade...

Mainframe conhece esses monstros desde que Elvis Presley ainda estava gravando discos.

A diferença é que o z/OS aprendeu a sobreviver a eles.

Hoje vamos entender como esses problemas surgem em:

COBOL
JCL
REXX
CICS
DB2
IMS
VSAM
Batch
JES2
SDSF
Language Environment

e principalmente...

como impedir que uma simples variável PIC X(10) provoque um incidente digno de abertura de War Room.

Capítulo 1

O que é Buffer Overflow?

Definição simples.

Você reservou espaço para 10.

Escreveu 100.

Fim.

Exemplo.

COBOL

01 WS-NOME.

   05 WS-TEXTO PIC X(10).



MOVE "BELLACOSA-MAINFRAME" TO WS-TEXTO

Teoricamente:

0123456789
BELLACOSA

Sobrou:

MAINFRAME

Para onde foi?

Depende.

Pode ir para:

Flag

Outra variável

LE Runtime

Heap

Stack

Linguagem C


char nome[10];

strcpy(nome,"BellacosaMainframe");

Mesmo problema.

COBOL apenas costuma esconder melhor.

Capítulo 2

Memory Overwrite

Buffer Overflow produz.

Memory Overwrite.

É o efeito colateral.

Exemplo

01 WS-AREA.

05 TABELA OCCURS 100.

10 COD PIC X.


05 FLAG PIC X.

Erro.

MOVE 'S'
TO TABELA(101)

Resultado.

FLAG = S

Pior.

Pode alterar:

SQLCA

DFHEIBLK

TGT

Save Area

Storage Corruption

É o estágio terminal.

Já não sabemos mais o que foi alterado.

O programa continua rodando.

Mas agora virou um zumbi.

O pesadelo

Job roda.

Termina RC=0000.

DB2 recebe dados errados.

VSAM inconsistente.

Extrato bancário incorreto.

E ninguém percebe.

Capítulo 3

Como o z/OS protege memória

1964

System/360

Quase nenhuma proteção.

Anos 70

Storage Keys

PSW

Anos 80

MVS/XA

Address Space

Anos 90

ESA

Cross Memory

Anos 2000

zOS

64 bits

Heap protegido

Hoje

z16

z17

Guard Pages

Hardware assistido

Storage protection

O conceito de Address Space

Cada Job.

Cada TSO.

Cada CICS.

Possui seu universo.

Imagine apartamentos.

Apartamento 101.

COBOL.

Apartamento 102.

DB2.

Apartamento 103.

JES2.

Overflow.

Quebrou parede.

Invadiu apartamento vizinho.

Sysprog chora.

Capítulo 4

Batch

Batch é perigoso.

Porque roda horas.

Exemplo

5 milhões registros.

Erro.

Registro 3.456.789.

Corrupção.

Abends comuns

S0C4

Protection Exception

S0C7

Dados inválidos

S0C1

Opcode ilegal

S878

Storage

S80A

Memória insuficiente

U4038

LE detectou problema

Caso histórico

Década 90.

Seguradora.

Tabela OCCURS 500.

Nova regra.

700 elementos.

Programa não recompilado.

Sobrescreveu área.

Job fechou mensal.

Milhares apólices erradas.

Descoberta.

3 semanas depois.

Capítulo 5

CICS

No online.

Muito pior.

CICS compartilha recursos.

Tasking.

Threads.

Erro.

Pode derrubar milhares usuários.

DFHEIBLK corrompido.

Retorno errado.

Pseudo-conversacional.

COMMAREA.

Overflow.

Exemplo

DFHCOMMAREA PIC X(32767)

Recebe.

40 mil.

Boom.

Abends famosos

AEI9

ASRA

AEYD

APCT

AICA

Loop infinito.

CPU consumida.

ASRA

Equivalente S0C4.

Capítulo 6

DB2

DB2 é robusto.

Mas aplicativo não.

SQLDA.

SQLCA.

Host Variables.

Exemplo

PIC X(10)

Coluna VARCHAR(100)

Truncation.

SQLCODE

-302

-311

-305

Melhor prática.

Verificar.

SQLCODE.

Sempre.

Capítulo 7

IMS

IMS é uma máquina do tempo.

Ainda vivo.

PCB errado.

SSA inválida.

Pode gerar.

U0777

Overflow.

Área I/O.

Segmento corrompido.

Capítulo 8

VSAM

KSDS.

RRDS.

ESDS.

Erro clássico.

Capítulo 9

REXX

Parece inocente.

Não é.

Stem.

CLIENTE.0=100

DO I=1 TO 1000

SAY CLIENTE.I

END

Dados inexistentes.

RC inesperado.

Storage não costuma corromper.

Mas lógica.

Sim.

Capítulo 10

JES2

JES2 protege spool.

Mas programa pode gerar.

100 milhões linhas.

SYSOUT gigante.

JES2 sofre.

HASP...

mensagens.

Spool cheio.

Job cancelado.

Capítulo 11

SDSF

Melhor amigo.

Status

Address Spaces

LOG

Mensagens

ENC

Enclave

Examine.

MEMORY.

CPU.

Abends.

Capítulo 12

LE

Language Environment.

Herói desconhecido.

SSRANGE

CHECK

HEAPCHK

RPTSTG

TRAP

TERMTHDACT

Exemplo

PARM='TRAP(ON)'

Captura.

Stack.

Dump.

Capítulo 13

Ferramentas modernas

Fault Analyzer

Abend Aid

IBM Debug

IPDF

CEEDUMP

SMF

110

120

RMF

OMEGAMON

Z APM

Capítulo 14

Como programar seguro

Sempre

SSRANGE

Validar índices.

IF IDX <= MAX

Nunca confiar input.

CHECK LENGTH

SQLCODE

RESP

CICS

FILE STATUS

ON SIZE ERROR

INITIALIZE

INSPECT

TESTAR.

Capítulo 15

Detectando antes do caos

Pipeline ideal.

DEV

SSRANGE

HEAPCHK

HML

TRAP

PRD

NOSSRANGE

SMF

OMEGAMON

Alarmes.

CPU.

Storage.

Abends.

Spool.

Response Time.

Easter Egg Bellacosa

Existe uma lenda em alguns datacenters.

Conta-se que um programa COBOL compilado em 1984 executava perfeitamente.

Até que um desenvolvedor júnior resolveu "modernizar".

Adicionou:

OCCURS 2000 TIMES

Compilou.

Promoveu.

Sexta-feira.

17h45.

Produção.

Fim de mês.

Folha salarial.

Executou.

RC=0000.

Tudo aparentemente perfeito.

Na segunda-feira descobriram que 12 mil funcionários haviam recebido exatamente:

R$ 0,01

O programa não havia abendado.

Não havia S0C4.

Não havia dump.

Apenas um discreto byte sobrescrito em uma área esquecida do Working Storage.

Dizem que o Sysprog responsável ainda hoje aparece pelos corredores do CPD segurando uma caneca de café e repetindo para novos desenvolvedores:

"Tem gente que teme IA substituir programadores. Eu temo programadores que compilam NOSSRANGE em homologação."

Conclusão

Os grandes incidentes em Mainframe raramente começam com uma pane espetacular.

Eles começam com pequenas negligências:

Um índice não validado;
Um OCCURS mal dimensionado;
Um SQLCODE ignorado;
Um COMMAREA maior que o esperado;
Um READ VSAM sem FILE STATUS;
Um JCL sem limites de espaço;
Um REXX assumindo que tudo sempre existe.

O z/OS evoluiu durante mais de 60 anos justamente para impedir que esses erros se transformem em catástrofes.

Mas a última linha de defesa continua sendo a mesma desde 1959:

O desenvolvedor que entende memória, respeita limites e trata cada MOVE como se estivesse carregando plutônio digital.

Translate

sábado, 5 de abril de 2025